Chaque composant fonctionne. Pourtant, le système échoue.

Personne n’a fait d’erreur.

Le hardware respecte ses spécifications. Le firmware aussi. Le logiciel aussi. Les communications fonctionnent.

Chaque équipe peut le démontrer.

Et l’ensemble est inutilisable.

Ce n’est pas un paradoxe. C’est un problème système.

La conformité locale ne garantit pas le résultat global #

Dans les deux Perspectives précédentes, nous avons posé deux idées.

Un symptôme ne révèle pas nécessairement l’origine d’un problème. Et un prototype qui valide une hypothèse ne valide pas automatiquement le produit qui en découlera.

Il reste une conséquence moins intuitive : plusieurs sous-systèmes parfaitement conformes peuvent produire ensemble un comportement non conforme.

Prenons un exemple volontairement simple.

• Un capteur fournit une mesure toutes les 100 ms.
• Une transmission peut ajouter 80 ms de latence.
• Un traitement logiciel nécessite 70 ms.

Indépendamment, ces trois performances peuvent parfaitement respecter leurs spécifications. Mais si l’usage exige une réaction complète en moins de 200 ms, leur combinaison peut devenir incompatible avec le besoin réel.

Aucun composant n’est défaillant. C’est l’architecture temporelle du système qui l’est.

Les interfaces ont elles aussi un comportement #

Et la temporalité n’est qu’un exemple.

Deux composants peuvent utiliser la même unité mais pas la même convention. Un algorithme peut supposer une qualité de signal que le capteur ne garantit que dans certaines conditions. Une liaison radio peut être excellente sur banc et perturbée une fois intégrée mécaniquement. Un système parfaitement fonctionnel peut devenir inutilisable simplement parce que son utilisateur se comporte différemment de ce qui avait été imaginé.

C’est ici que les systèmes complexes deviennent intéressants : certaines propriétés n’appartiennent à aucun composant. Elles émergent de leurs interactions.

Changer d’échelle #

Lorsqu’une équipe a vérifié dix fois chaque composant sans trouver le problème, la onzième vérification n’est pas toujours la meilleure utilisation de son temps.

Il peut être nécessaire de changer d’échelle.

• Observer les interfaces.
• Reconstituer les séquences.
• Mesurer les conditions réelles.
• Tester les hypothèses partagées entre équipes.

Et surtout revenir à la question la plus importante : « quel comportement attendons-nous réellement du système complet ? »

L’ingénierie système ne remplace pas les expertises spécialisées. Elle permet de comprendre ce qui apparaît lorsqu’on les assemble. Et parfois, le problème le plus difficile à résoudre n’appartient précisément à aucune d’entre elles.

Nous avons jusqu’ici parlé de systèmes dont nous savons ce qu’ils devraient faire. Mais en R&D, la situation devient plus étrange : parfois, nous ne savons même pas encore si ce que nous cherchons est possible.

Perspective 04 — lundi prochain : L’échec expérimental est une donnée.

Sources #

• INCOSE — travaux sur les comportements émergents dans les systèmes complexes.
• NASA — Systems Engineering Handbook, intégration et validation des systèmes.