Leçons tirées de la gestion des exigences : défaillances de conversion d’unités

Dans le développement de produits matériels, les ingénieurs manipulent des chiffres tous les jours. Une valeur passe d’un ingénieur à un plan, d’une spécification à un composant, ou de votre équipe à un fournisseur. La plupart du temps, cela fonctionne parce que tout le monde sait ce que signifie le nombre et quelle unité il utilise.

Le risque apparaît lorsque cette valeur franchit une étape de transfert et que les deux parties ne l’interprètent pas de la même manière. L’une peut travailler en livres tandis que l’autre s’attend à des kilogrammes. Un document peut utiliser une ancienne conception en système impérial, alors que le nouveau projet est métrique. Le nombre peut sembler correct des deux côtés, mais il ne guide plus la même décision.

Les trois histoires d’ingénierie ci-dessous montrent à quel point cela peut arriver facilement :

Trois cas, un même schéma

Trois défaillances d’ingénierie, sur trois décennies, montrent le même problème de transfert sous des formes différentes. Dans chaque cas, un nombre est passé d’une partie du flux de travail à une autre. Le nombre semblait juste pour les utilisateurs, mais deux systèmes de mesure étaient en jeu. Le transfert n’a pas clarifié quelle unité le nombre utilisait.

Vol 143 d’Air Canada : le planeur de Gimli

Le premier exemple est le planeur de Gimli de 1983. Il montre ce qui s’est passé lorsqu’une compagnie aérienne, Air Canada, est passée des unités impériales aux unités métriques. Le vol 143, un Boeing 767 reliant Montréal à Edmonton, était son premier avion métrique.

Ce jour-là, le système d’indication de quantité de carburant (FQIS) ne fonctionnait pas, donc l’équipage a mesuré le carburant manuellement. Il a utilisé la valeur de densité du ravitailleur de 1,77, en livres par litre, la norme pour le reste de la flotte. Mais le 767 métrique avait besoin de cette valeur en kilogrammes par litre, où le bon nombre était d’environ 0,8.

L’avion a décollé avec seulement la moitié du carburant attendu par l’équipage, ce qui a provoqué l’arrêt des deux moteurs en vol. Heureusement, les pilotes ont réussi à l’atterrir en toute sécurité.

Mars Climate Orbiter

Seize ans plus tard, le Mars Climate Orbiter a été perdu à cause d’une erreur de navigation provoquée par un échec de conversion des unités anglaises en unités métriques. Le logiciel de Lockheed Martin envoyait les données des propulseurs en livres-force seconde. Le logiciel de navigation de la NASA attendait des newton-secondes, qui diffèrent des livres-force seconde par un facteur de 4,45.

Le vaisseau spatial devait se placer en orbite entre 150 et 200 kilomètres au-dessus de Mars. Au lieu de cela, il est descendu jusqu’à environ 57 kilomètres et s’est consumé dans l’atmosphère martienne.

Les montagnes russes Space Mountain de Tokyo Disneyland

En 2003, les montagnes russes Space Mountain de Tokyo Disneyland ont révélé un problème similaire à travers les plans de conception. L’attraction avait été redessinée du système impérial au système métrique en 1995, en faisant passer le diamètre d’un essieu de 44,14 à 45 millimètres. Cependant, les anciens plans n’ont pas été retirés de l’usage et, par conséquent, il existait deux jeux de plans de conception.

En 2002, lorsqu’un nouvel ensemble d’essieux a été commandé, la commande s’est appuyée sur la version de conception antérieure à 1995. Les pièces ont donc été livrées sous-dimensionnées. Cette différence de 0,86 millimètre a rendu le jeu du roulement bien plus important que prévu. Après des mois d’utilisation, l’essieu s’est cassé.

Dans ces trois cas, le nombre lui-même ne paraissait pas suspect. Le problème a commencé lorsque ce nombre est devenu la base de l’étape d’ingénierie suivante, et que son unité ou sa source n’était pas assez claire.

Cette illustration rappelle qu’une valeur peut sembler correcte à tout le monde et malgré tout être erronée : les deux parties de votre transfert sont-elles d’accord sur l’unité ?

Ce que les équipes hardware peuvent apprendre de ces histoires

La plupart des équipes hardware ne pilotent pas d’avions et ne lancent pas de vaisseaux spatiaux. Pourtant, des transferts similaires se produisent chaque jour. Une valeur passe d’une exigence à un plan, d’une spécification à un composant, ou de votre équipe à un fournisseur. À chaque transfert, l’unité doit rester associée au nombre. Trois pratiques peuvent aider :

Spécifiez les unités pour chaque valeur d’exigence

Un nombre seul ne suffit pas. « 45 » n’indique pas à la personne suivante quoi fabriquer ou quoi tester. « 45 mm » donne du sens au nombre. Gardez l’unité à côté de la valeur à chaque fois. Ce n’est pas un détail de mise en forme ; cela fait partie de l’exigence.

Attribuez clairement la responsabilité lors des transferts d’ingénierie

Les confusions d’unités surviennent souvent lorsque l’information passe d’une équipe à une autre. Une partie peut travailler à partir d’une référence, tandis que l’autre en attend une autre. Ce transfert a besoin d’un responsable clairement identifié. Quelqu’un doit vérifier le système d’unités, le format des données et le document source avant que la valeur ne soit utilisée en aval.

Gardez les exigences et les preuves traçables

Lorsqu’une valeur change, l’équipe doit pouvoir trouver ce qui en dépend. Cela signifie que l’exigence, le plan, le composant, le test et les preuves ne doivent pas exister comme des éléments déconnectés. La traçabilité aide l’équipe à voir d’où vient une valeur, ce qui l’utilise et ce qui doit être revu lorsqu’elle change.

Comment un workflow d’exigences connecté aide

Un meilleur workflow d’exigences maintient le nombre, son unité, son responsable et le document source proches les uns des autres. Il ne traite pas la valeur comme un simple nombre isolé dans une feuille de calcul, un plan ou une spécification.

Cela est particulièrement important lors des transferts. Lorsqu’une valeur passe d’une exigence au travail de conception ou de vérification, la personne suivante peut voir ce que signifie la valeur, quelle unité elle utilise et d’où elle vient. Si la valeur change, l’équipe peut également identifier ce qui doit être revu.

Altium Requirements Portal prend en charge ce type de workflow en réunissant exigences, responsabilités, traçabilité et activités de vérification dans un environnement partagé. Il ne remplace pas le jugement des ingénieurs. Il aide à garder visibles l’unité, le responsable et le contexte d’ingénierie associé avant qu’une valeur ne soit utilisée en aval.

Points clés à retenir

• Les confusions d’unités commencent souvent lors des transferts, lorsqu’une valeur passe à une autre équipe, à un autre document ou à un autre système sans que son unité soit clairement précisée.
• Avant qu’un nombre ne guide l’étape d’ingénierie suivante, l’équipe doit savoir d’où il vient et à qui il appartient.
• La traçabilité aide les équipes à voir ce qui dépend d’une valeur avant qu’elle ne change ou ne soit transmise en aval.

Chaque nombre de votre projet est-il complet ?

Chacun de ces incidents aurait pu être évité. Non pas avec une meilleure ingénierie, mais avec des questions claires posées au moment du transfert :

• Chaque valeur de vos exigences comporte-t-elle une unité ?
• Chaque interface entre équipes a-t-elle une personne responsable ?
• Est-il clair quelle version d’une spécification est la version en vigueur ?
• Si quelque chose changeait demain, votre processus montrerait-il ce qui doit être revu ?

Posez-vous maintenant les mêmes questions à propos de votre projet. Si la réponse à l’une d’elles est « probablement », vous savez déjà par où commencer.

Gardez les informations d’ingénierie importantes claires et faciles à vérifier à chaque transfert grâce à un outil de gestion des exigences que toute votre équipe peut utiliser.

Commencez avec Requirements Portal →

Questions fréquemment posées

Pourquoi les erreurs de conversion d’unités se produisent-elles dans les projets d’ingénierie ?

Ces confusions viennent rarement de mauvais calculs. Elles se produisent lors des transferts, lorsqu’une valeur passe entre équipes, outils ou documents. Une partie peut supposer que la valeur est dans une unité, tandis que l’autre la lit dans une autre. La valeur peut donc rester correcte, mais elle est correcte pour une mauvaise hypothèse.

Que doit contenir une valeur d’exigence complète ?

Une valeur d’exigence complète doit inclure le nombre, l’unité et le contexte nécessaire pour l’utiliser correctement. Par exemple, « 45 » ne suffit pas ; « 45 millimètres » oui. L’équipe peut aussi devoir connaître la condition dans laquelle la valeur s’applique, le document source et le responsable de cette exigence.

Comment la traçabilité aide-t-elle à réduire les erreurs de transfert ?

La traçabilité relie une valeur à tout ce qui en dépend : de l’exigence de plus haut niveau jusqu’au composant, au test et au responsable associés. Lorsqu’une valeur change, ces liens facilitent l’identification de tout ce qui peut nécessiter une revue. Cela réduit le risque qu’une ancienne spécification, une unité peu claire ou un test obsolète reste utilisé par erreur.