Secteur
Transport
Le secteur transport développe des systèmes où la sûreté n'est pas négociable. Signalisation ferroviaire, contrôle-commande, billettique, systèmes embarqués dans le matériel roulant : la part logicielle de ces systèmes ne cesse de croître, avec des niveaux d'intégrité à maintenir et des architectures de plus en plus complexes à maîtriser.
Enjeux
Ce que nous observons chez nos clients du secteur transport
Les organisations maîtrisent leur domaine technique. Elles maîtrisent moins bien la complexité de développement qui en découle.
Un développeur de systèmes de signalisation, un fournisseur de solutions billettiques : leur savoir-faire métier est rarement en cause. Ce qui l'est, c'est la capacité à piloter des développements où plusieurs sous-systèmes interagissent, où les exigences se ramifient entre acteurs, où la traçabilité doit tenir sur cinq ou dix ans de programme. L'ingénierie système n'est pas encore un réflexe — c'est souvent une réponse tardive à un problème déjà visible.
Les symptômes sont connus : interfaces mal définies, exigences perdues en cours de route, livraisons qui glissent sans qu'on sache vraiment pourquoi.
Ce n'est généralement pas un problème de compétence technique. C'est un problème de cadre : des rôles d'ingénierie mal positionnés, des pratiques non partagées entre équipes ou entre sous-traitants, une qualité gérée en bout de course plutôt qu'en amont.
Dans ce secteur, la maturité des processus est souvent une exigence contractuelle, pas seulement un objectif interne.
CMMI reste un modèle de référence dans de nombreux programmes de transport, notamment dans les appels d'offres publics et les démarches d'évaluation fournisseurs. L'enjeu pour les équipes n'est pas de "passer" une évaluation : c'est de construire des pratiques qui tiennent dans la durée et qui produisent un bénéfice réel, pas une couche documentaire supplémentaire.
CMMI®
Ingénierie des systèmes
MBSE
Enjeux du secteur
- Développer des systèmes embarqués à logiciel prépondérant avec des exigences de sûreté de fonctionnement et de certification
- Maintenir la cohérence des exigences et des interfaces dans des programmes longs, multi-acteurs, impliquant de nombreux sous-systèmes
- Répondre aux exigences contractuelles sur la maturité des processus (CMMI) sans que l'exercice se réduise à de la conformité sans bénéfice réel
- Tenir les engagements de livraison sur des cycles longs, sans que les pratiques d'ingénierie se dégradent en cours de route
Où notre approche fait la différence
- MBSE Snake® : l'ingénierie des systèmes / MBSE accessible aux non-spécialistes et adaptée au contexte innovation / advanced engineering
- Fast & Serious® : la combinaison de la rigueur de l'ingénierie et de l'accélération du flux de valeur
- CMMI® : une expertise de CMMI Lead Appraiser, mobilisée dans les contextes contractuels et utilisée comme levier d'amélioration réel, pas comme un simple exercice de compliance
- Accompagnement terrain au plus près des équipes et des outils existants
Ils nous font confiance
Exemples de missions
Ce que nous avons fait concrètement
Deux exemples d'interventions représentatives de notre approche dans le secteur transport.
Sécuriser l'obtention d'un niveau de maturité 2 CMMI
Un acteur du transport ferroviaire visait un niveau de maturité 2 CMMI pour ses activités de développement logiciel, afin notamment d'accéder à de nouveaux marchés et de renforcer la satisfaction client. L'enjeu : déclencher l'évaluation officielle au bon moment, une fois l'organisation prête, mais avant la date limite pour ce type d'évaluation.
Mission
- Identifier les écarts au regard du référentiel CMMI-DEV niveau 2 et aider à construire le plan d'actions de mise à niveau
- Mener des Readiness Reviews itératives et statuer sur le Go / No Go selon l'état de préparation
- Conduire l'évaluation officielle SCAMPI A en tant que Lead Appraiser
Résultat
- 2 "Readiness Reviews" concluant à un report assumé
- Mise à niveau réalisée, notamment sur les aspects "Mesures & Analyses"
- Niveau de maturité 2 CMMI obtenu officiellement, le jour même de la date limite pour les évaluations SCAMPI A en V1.3
Répondre aux exigences contractuelles d'ingénierie système sur un projet de billettique
Suite à l'obtention d'un contrat avec un opérateur de transport public, un éditeur de solutions de billettique devait répondre à une clause contractuelle imposant de démontrer sa conformité aux pratiques d'ingénierie système (ISO15288) et de gestion de configuration (EIA649).
Mission
- Réaliser un diagnostic des pratiques mises en oeuvre sur le projet par rapport à ISO15288 et EIA649
- Clarifier le rôle et les livrables d'un Architecte Technique
- Définir son positionnement vis-à-vis des Business Analysts, aux Technical Leads et aux Architectes Infrastructure
Résultat
- Rapport de diagnostic ISO15288 / EIA649 avec plan d'amélioration priorisé
- Langage commun (ontologie) pour décrire l'architecture du système de billettique
- Mise en pratique opérationnelle des recommandations : diagrammes d'architecture révisés et adoptés sur les nouvelles affaires
- Templates de description d'architecture d'un système de billettique : architecture opérationnelle, architecture technique et architecture sous-système
Vous souhaitez discuter de votre contexte ?
Nous ne proposons pas de solution toute faite. Mais si les enjeux décrits ici résonnent, parlons-en.