Le problème n'est pas toujours là où l'on vous dit de regarder

Tout fonctionne.

Le logiciel répond. Le capteur mesure. Les données circulent. Les tests unitaires passent.

Pourtant, le système ne fonctionne pas correctement.

Le réflexe naturel consiste alors à chercher quel composant est défaillant.

Et si aucun ne l’était ?

Un système n’est pas la somme de ses composants #

Décomposer un problème complexe est une excellente méthode d’ingénierie. Elle permet d’isoler, mesurer et valider chaque fonction.

Mais elle possède une limite : le comportement observé à l’échelle du système peut provenir des interactions entre ses composants, et non d’un composant pris isolément.

L’ingénierie système s’intéresse précisément à ces relations : interfaces, dépendances, séquences, contraintes physiques, temporalité ou encore environnement.

L’INCOSE parle notamment de propriétés émergentes pour désigner des phénomènes qui apparaissent au niveau du système sans être présents au niveau de ses éléments pris séparément.

Un capteur peut donc être parfaitement conforme à sa spécification. Le logiciel qui exploite ses données aussi. La communication entre les deux également. Et leur combinaison produire malgré tout un résultat incorrect.

Chercher la cause, pas le coupable #

Face à ce type de problème, demander « quel composant ne fonctionne pas ? » peut enfermer l’analyse trop tôt.

Une question souvent plus utile est : « quelles conditions doivent être réunies pour produire le comportement que j’observe ? »

On ne cherche plus immédiatement un coupable. On reconstruit une chaîne causale.

Cela oblige parfois à traverser plusieurs domaines : logiciel, électronique, mécanique, radio, traitement du signal, réseau ou simplement comportement humain.

C’est souvent aux frontières entre ces domaines que les hypothèses deviennent invisibles.

• Une donnée considérée comme fiable ne l’est peut-être que dans certaines conditions.
• Une latence négligeable indépendamment devient critique dans une séquence complète.
• Deux composants conformes peuvent avoir des hypothèses d’interface incompatibles.

Tester les relations #

La conséquence est très concrète.

Tester séparément les composants d’un système valide les composants. Cela ne valide pas nécessairement le système.

Il faut également tester les interfaces, les séquences et le comportement de bout en bout. C’est notamment pour cette raison que les démarches d’ingénierie système distinguent la vérification des éléments de leur intégration et de la validation du système complet.

Lorsqu’un projet technique semble bloqué malgré des composants individuellement fonctionnels, continuer à améliorer chacun d’eux peut donc être exactement la mauvaise stratégie.

Il faut parfois arrêter de regarder les pièces. Et commencer à regarder ce qui se passe entre elles.

Perspective 02 — lundi prochain : Un PoC qui fonctionne ne prouve pas que vous avez un produit.

Sources #

• NASA — Systems Engineering Handbook, Product Integration & Verification/Validation.
• INCOSE — travaux sur l’émergence et les systèmes complexes.