Software – Le Design invisible

Pourquoi mettre dans la même phrase Software et Design Invisible ? Veut-on dire par là que les lignes de code des programmes informatiques ne peuvent jamais être vues ou lues? Bien sûr que non ! Ce qui est suggéré ici, c’est le fait que le design, qui prend ici le sens anglais de conception et plus particulièrement le sens de conception software (1) reste obscure. Le code qui bien qu'il soit visible, n'est le plus souvent compréhensible, que pour celui qui l'a écrit. Les collègues devront lors d’une peer review (2), s’ils veulent en faire une critique constructive, passer pour le comprendre, le même temps qu’il a fallu pour l’écrire. Le fonctionnement du produit software est donc, en quelque sorte, un peu invisible

Invisible, tant que ça marche, ça va ... mais voilà ! Des fois, ça ne marche plus; et on ne sait pas pourquoi. Alors on s’efforce ici ou là de rendre le code compréhensible et les remèdes locaux des changements apportés font que ça fonctionne de nouveau mais en créant des interactions avec d’autres morceaux du code qui créeront certainement de nouveaux problèmes plus tard ; problèmes qu’on va appréhender avec une anxiété bien légitime.

Alors, pris par le temps, on finit par délivrer et éventuellement on continuera de débugger une fois en production chez le client. Si le client est captif, pas de soucis … tant qu’il est d’accord pour payer pour les problèmes Qualité. Les clients vont accepter de communiquer les bugs dont ils souffrent (3)  et d’attendre les solutions et ça peut continuer pour autant qu’il n’y a pas d’offres concurrentes, que l'application business n'est pas trop critique ou que les bugs ne représentent pas un danger de mort.

Danger de mort, application critique et compétition agressive est le lot habituel des métiers de la mécatronique ou des ERP (Enterprise Resource Planning); comme chez les constructeurs automobiles par exemple. Métiers où l'électronique et l'informatique prennent de plus en plus de place et où l'on parle de la Google Car. Là les marges sont petites, les volumes énormes et les risques très grands. Dans ces conditions faire des erreurs est juste inacceptable car les erreurs peuvent tuer des personnes ou faire disparaître l’entreprise.

L’industrie automobile utilise depuis des dizaines d’années les outils et processus de prévention des modes de défaillance pour le développement et la fabrication de ses pièces hardwares (4) et ce avec un succès certain. Il s’agit pour l’équipe de développement principalement de se réunir autour d’un plan d’ingénieur et d’en critiquer la conception avec des outils comme peuvent l’être l’AMDEC (Analyse des Modes de Défaillance, de leurs Effets et de leur Criticité).

On aura auparavant préparé le travail de l’AMDEC avec d’autres outils comme l’étude des modes de variation de chaque entrée clé du produit. Travail rendu possible par l’analyse fine des parties élémentaires des sous-systèmes du produit. Car il faut savoir qu’un produit hardware tombe toujours en panne à cause d’un problème de variation d’un de ses composants. Effectivement, tant qu’on reste autour des valeurs nominales prévues en conception, ça fonctionne. Et c’est quand on s’en éloigne que les problèmes commencent.

On se triture donc l’esprit à l’aune du plan d’ingénieur que l’équipe a sous les yeux et on propose telles ou telles améliorations afin de réduire les risques, et ce :

A) En réduisant l’impact du composant sur le système hiérarchiquement supérieur dont il est la source de fonctionnement et/ou en réduisant le risque de défaillance du composant (5).

B) En mettant en place des contrôles afin de réduire ou totalement empêcher l’effet négatif sur le client si le problème devait malgré tout survenir.

Finalement on vérifiera l’impact des changements liés aux améliorations sur le reste du produit en mettant à jour les autres outils de prévention des modes de défaillance comme principalement l’enchainement des maisons de la qualité (cf. House Of Quality) ou encore la cartographie des fonctions attendues et subies du système. L’approche est systématique et si appliquée de façon rigoureuse par exemple à l'aide d'un outil comme le Companion de Minitab est payante. Les clients apprécieront la robustesse du produit dont ils peuvent exiger la performance pour laquelle ils auront payé le prix. Produit qui le plus souvent pardonnera également leurs erreurs d’utilisation car ces erreurs ont été envisagées, prévues et rendues acceptables lors de la conception par le fournisseur qui bénéficiera alors d’une base de clients fidèles car confiants.

Cependant, aujourd’hui à l’heure du numérique, l’industrie automobile voit, comme bien d’autres, son métier changer avec l’intégration grandissante et inexorable de l’électronique. Tous les métiers changent car ils sont confrontés à un nouveau type de design. Le Design Invisible.

Les outils de prévention des modes de défaillance qui ont été cités plus haut dans ce texte, doivent maintenant prendre en compte l’aspect software et les qualiticiens originellement formés à la critique des plans hardwares doivent évoluer afin d’intégrer cette nouvelle contrainte. Car enfin, comment pourrait-on imaginer que ces mêmes qualiticiens en charge de la fiabilité : d’un côté s’arrachent les cheveux avec les équipes de développement hardware afin de concevoir le meilleur produit, mais de l’autre côté, acceptent avec une foi toute religieuse les boîtes noires que sont les objets softwares (5) livrés par les équipes informatiques. Ça n’est pas raisonnable.

Alors quoi faire ? Car enfin, puisqu’il faut changer, comment s’y prendre ?

Commençons par l’AMDEC, véritable clé de voute de la qualité. Est-elle applicable ? On peut l’envisager mais en fait on s’aperçoit rapidement que l’outil n’est pas bien adapté tel quel, car quand on se prête à l’exercice, on se rend compte que par exemple l’Occurrence (5) ne peut plus être évaluée en estimant ce qui peut : frotter, bouger, casser, chauffer … dans le design. Le problème ne s’exprime plus de façon physique. Effectivement un software est un ensemble de lignes de code, et donc de formules logiques qui ne peuvent pas, à moins d’un changement de type tout-ou-rien comme par exemple une affection électromagnétique qui vient changer le code source, souffrir de variation continue. Un programme délivrera nécessairement toujours le même résultat si il est soumis aux mêmes entrées. Aucun changement quantitatif (également appelé variable ou continu) ne peut être de son fait.

Alors d’où viennent les pannes ? Car si le code ne peut souffrir d’aucune variation continue, les pannes, elles, existent pourtant bien. Quiconque a déjà eu à faire à un ordinateur le saura.

Elles proviennent en fait de tous ces cas qui surgissent en-dehors de l’utilisation prévue et qui n’ont pas été pris en compte. Les entrées ne sont alors plus ce qu’elles sont censées être et le programme plante. On parlera alors d’un changement qualitatif (également appelé discret ou attribut).

Pour découvrir ces cas (et ensuite y remédier), il va donc falloir mettre en œuvre les outils de créativité systématique de TRIZ (7) dans le cadre de tests exploratoires. Ce travail exploratoire permet grâce au processus de créativité systématique TRIZ d’être rigoureux et exhaustif.

Ensuite on éprouvera l’objet software par une panoplie de tests vérifiant la performance et la fiabilité des fonctions attendues et subies de type ALT ou HALT (Accelerated Life Testing ou Highly …). La modélisation statistique de fiabilité fournira par ailleurs un indice que l’on pourra alors utiliser entre autres comme valeur d’Occurrence dans l’AMDEC.

Finalement on pourra en profiter pour combiner la fiabilité ainsi estimée avec celles des autres parties du système. On déterminera ainsi le maillon faible et sa fiabilité. Ce qui en fin de compte, permettra de confronter la durée de vie estimée du produit par rapport au besoin client et typiquement, quand le produit sera finalement meilleur que celui de la concurrence, en faire un argument de vente.

Nous n’abordons dans ce papier que les aspects de prévention des modes de défaillance mais il faut également savoir que tout cela fonctionne main dans la main avec la méthode Agile (Scrum inclus) (8) qui permet de délivrer rapidement et régulièrement des morceaux de produit fonctionnels. Agile s’est inspiré du Lean Manufacturing (9) et ce pour rendre les développements informatiques plus véloces et donc d’être plus proches du besoin client. Depuis 15 ans qu’Agile a prouvé son efficacité, la méthode est redéployée pour les développements de l’industrie manufacturière (voir www.jugglingparadigms.com/fr/video/Robustesse @ 9:37).

La combinaison des méthodes de prévention des modes de défaillance et d'Agile garantit donc la fiabilité mais aussi avec avantage collatéral, le développement rapide du produit !
Thierry MarianiAuteur : Thierry Mariani – Juggling Paradigms Sàrl
DFSS and TRIZ innovation expert
Lean Six Sigma Master Black Belt – ISSSP Scottsdale USA
MSc. Mechanical / Automotive Engineering – CNAM Paris, France
Connect with Thierry on LinkedIn at: www.linkedin.com/in/thierrymariani

-----------------------------------------------------------------------------------------------------------------------------------------------------------

(1) Software dans le sens de produit « souple » (mais cela s’applique ici également au Firmware quand on parle d’informatique embarquée). Souple pour symboliser l’écriture d’une formule mathématique qui produira un effet par la médiation d’un appareil électronique, effet pour lequel le client est prêt à payer le prix.

(2) Peer Review est un mot anglais qui veut dire réunion avec ses pairs pour ici critiquer le code de façon constructive.

(3) Certains vont même jusqu’à demander la carte de crédit du client, afin qu’il ait le droit de communiquer les bugs dont il souffre.

(4) Hardware dans le sens de produit « dur ». Dur pour indiquer la conception figée des produits manufacturés.

(5) Trois aspects doivent être pris en compte pour estimer la valeur d’Occurrence (L’Occurrence est l’une des trois valeurs à renseigner dans une AMDEC ; les deux autres étant l’Effet et la Détection. Détection qui fait partie du contrôle et qui est expliqué au point B ci-dessus):

  • La sensibilité de la sortie désirée (Y en mathématique) par rapport à l’une de ses entrées clés que l’on a identifiée ici comme étant le composant (Xi en mathématique). Pour plus d’explications, veuillez visiter notre site www.jugglingparadigms.com/fr/video/Robustesse @ 2:20
  • La sensibilité du composant Xi par rapport à l’un de ses facteurs de bruit (Ni) tels que : détérioration dans le temps, environnement opérationnel, les interactions avec d’autres systèmes/sous-systèmes, la variation entre pièces, l’utilisation en dehors des limites opérationnelles du client.
  • La quantité de variation du bruit Ni.
(6) On parle d’objet software car l’effet attendu des lignes de codes, s’exprime à travers la médiation de l’appareil électronique qui les contient.

(7) TRIZ est une méthode et un acronyme russe qui signifie “résolution des problèmes par la créativité”. TRIZ est composé d’un ensemble vaste d’instruments de créativité et est considéré aujourd’hui et à juste titre comme l’un des processus les plus puissants pour faire en sorte et de façon répétable qu’une équipe soit créative et ce quels que soit les membres qui la composent.

(8) Agile/Scrum sont deux approches, que l’on peut distinguer ainsi :

-La première fait référence à la philosophie de l’agilité qui promeut l’idée de flexibilité dans le développement et ce afin de contraster avec l’image de rigidité de la méthode en cascade ou Waterfall à laquelle on associe l’idée d’un développement en bloc et en marge du client. L’image véhiculée par le Waterfall étant qu’après avoir obtenu la signature du contrat, on va développer en fonction du cahier des charges dans son coin pendant des mois et qu’au final on délivre un produit qui ne correspond pas ou plus aux désidératas du client car soit le contexte a changé, soit on n’avait pas pensé à un certain nombre de choses critiques, soit le cahier des charges a été mal compris, mal écrit, mal suivi, etc.

-Et la deuxième fait référence à la méthode de travail Scrum qui est le nom anglais de la mêlée que font les Rugbymen pendant les matchs. Le Scrum serait donc la façon de faire des développements de type Agile. La métaphore de la mêlée représente l’idée du mélange et de la confrontation du rapport besoins/solutions que l’équipe du fournisseur (typiquement en informatique composée : des développeurs, testeurs, Scrum Master) va avoir avec le client lors des réunions de fin de sprint (Itération de développement entre la prise en charge d’un besoin client et la livraison d’une solution fonctionnelle pour répondre à ce besoin. Le Sprint a typiquement une durée d’une voire deux semaines.).

(9) Lire du même auteur : http://www.jugglingparadigms.com/fr/nos-references/agile-scrum-plus-six-sigma