Du cahier des charges à la solution : l'art de la spécification

Un projet qui démarre avec des exigences floues finit rarement bien. Sur les systèmes critiques où j'interviens, en aéronautique comme en ferroviaire, cette réalité est encore plus brutale : une simple ambiguïté dans une spécification peut se traduire par un défaut de sécurité ou une non-conformité réglementaire.

Le problème des exigences mal définies

J'ai vu trop de projets partir sur de mauvaises bases. Un besoin exprimé comme « un système performant » sans jamais définir ce que performance veut dire ; une fonctionnalité décrite par « ça doit marcher comme sur l'ancien système », sans autre précision. Le résultat ne varie guère : l'équipe développe quelque chose, le client découvre que ce n'est pas ce qu'il attendait, et l'on recommence.

L'ingénieur comme traducteur

Mon rôle ne commence pas au clavier. Il commence en amont, dans la compréhension du besoin : le contexte opérationnel, les contraintes métier, les enjeux qui justifient la demande.

Prenons un cas concret. Sur un projet ferroviaire, on me demande « un système qui affiche la vitesse du train ». Les questions arrivent aussitôt : quelle précision, quelle fréquence de rafraîchissement, quelle résilience en cas de panne capteur ? Ce sont elles qui transforment une demande vague en exigence mesurable.

Écrire une exigence exploitable

Chaque exigence doit être spécifique, mesurable et tracée jusqu'à un besoin identifié. Sur les systèmes critiques (DO-178C en aéronautique, CENELEC EN 50128 en ferroviaire), cette traçabilité n'est pas une option : chaque ligne de code doit répondre à une exigence identifiée.

Les étapes que je suis

1. Clarifier le besoin, via des ateliers avec les experts métier et la méthode des « 5 pourquoi » pour remonter du symptôme au vrai besoin.

2. Formaliser les exigences : numérotées, formulées à l'impératif (« doit »), chacune assortie d'un critère de validation.

3. Faire une revue croisée, validée par le métier, la technique et le client, pour détecter tôt les incohérences.

4. Assurer la traçabilité, en reliant chaque exigence à un besoin, puis à une conception, du code et des tests.

Ce que ça change concrètement

Une étude régulièrement citée en ingénierie estime qu'une erreur de spécification coûte bien plus cher à corriger en production qu'en amont. Sur mes projets, investir une journée dans une spécification rigoureuse évite systématiquement des semaines de retravail. Cet effort facilite aussi grandement les audits de certification, où chaque exigence réglementaire doit être tracée jusqu'au code.

En résumé

Spécifier, c'est traduire un besoin métier en exigences techniques sans perdre de sens en route. C'est un exercice d'écoute et de rigueur que je place toujours avant la première ligne de code, et c'est souvent lui qui décide si le projet avancera sans accroc ou tournera au parcours du combattant.