Fiabilité logicielle : les systèmes ne doivent pas vous lâcher au mauvais moment

La plupart des pannes critiques n'arrivent pas par surprise. Elles arrivent parce que personne n'avait posé la bonne question au bon moment : est-ce que ce système est vraiment fiable ou est-ce qu'on l'espère juste ?

Tant que la machine fonctionne, d'autres priorités prennent le dessus. Le souci réside dans le fait que lorsque cela cesse de fonctionner, les répercussions ne correspondent souvent pas au temps qu'on aurait pu investir pour éviter le problème.

La fiabilité logicielle a longtemps été un sujet réservé aux techniciens. Erreur : lorsqu'un système tombe en panne dans un domaine crucial comme la finance, la défense, la santé, l'administration publique, ce sont généralement les ingénieurs qui ne sont pas les premiers à prendre en charge les répercussions. Ce sont les dirigeants qui doivent rendre des comptes devant les actionnaires, les régulateurs et l'opinion publique. Ils sont directement impliqués sur le plan juridique, financier et moral. Un bug n'est pas un détail technique : c'est un risque stratégique.

Fiable ne veut pas dire « ça ne plante jamais »

Il s'agit du premier malentendu à dissiper. Un logiciel de confiance ne signifie pas un logiciel sans faille, cela n'existe pas. Cela signifie un logiciel dont on comprend les limites, dont les points de vulnérabilité ont été identifiés, testés, documentés. Et qui, quand quelque chose part de travers, tombe de façon contrôlée plutôt que d'emporter tout le reste avec lui.

Cette distinction a une importance tangible dans les systèmes critiques : en défense, un système de commandement qui se fige lors d'une opération ne prévient pas, il disparaît. Il en va de même dans la finance de marché, les infrastructures publiques ou la santé. Un système capable de détecter sa propre défaillance et de basculer en mode dégradé en trente secondes est radicalement différent d'un système qui se fige silencieusement et reste inaperçu pendant deux heures. Le premier se maîtrise, le second ne se révèle qu'une fois le dommage installé.

La bonne nouvelle, c'est que ce degré de fiabilité logicielle n'est pas exclusif aux organisations disposant de budgets démesurés. Cela dépend essentiellement de la méthode utilisée et de déterminer que c'est une priorité avant qu'un incident ne force la décision.

Une statistique qui devrait nous interpeller : selon le NIST, corriger un bug en production coûte entre 15 et 30 fois plus cher qu'en phase de développement. Le véritable enjeu n'est donc pas de dépenser davantage, mais de dépenser au bon moment.

Trois questions à poser à vos équipes, sans nécessité de compétences techniques

Il n'est pas nécessaire de comprendre le fonctionnement d'un compilateur pour juger de la solidité de vos systèmes. Les réponses à ces trois questions vous diront beaucoup.

Qui effectue les tests sur nos logiciels critiques ?

Si c'est la même équipe qui les a développés, il y a un risque. Les tests indépendants, la génération automatique de scénarios et la vérification formelle permettent de détecter ce que l'équipe n'aurait pas pensé à vérifier.

Quand nos systèmes legacy ont-ils été audités pour la dernière fois ?

Les systèmes anciens, comme des millions de lignes de COBOL encore en production dans la finance et l'administration, peuvent contenir des failles inattendues. Les mises à jour et nouvelles intégrations créent des risques invisibles si personne ne les contrôle. C'est souvent ça, une défaillance logicielle silencieuse.

Que se produira-t-il précisément si ce système cessait de fonctionner demain ?

Un risque logiciel que l'on ne peut pas décrire précisément est un risque qu'on ne maîtrise pas. Définir les conséquences permet d'anticiper et de planifier la mitigation. Et un risque qu'on ne gère pas, c'est un risque qui gère à votre place.

Ce que font différemment les organisations où l'erreur n'est pas une option

Nous avons travaillé avec des organisations opérant dans la défense, l'administration fiscale et la finance de marché. Ce qui les distingue des autres, ce n'est pas leur budget, mais leur rapport à la preuve : elles ne se contentent pas de faire confiance, elles vérifient.

En pratique, elles ne mettent pas en place un système critique en pensant simplement « les tests ont été réussis, tout devrait bien se passer ». Elles produisent automatiquement des milliers de scénarios afin de prendre en compte des cas que même leurs propres ingénieurs n'auraient jamais rédigés. Elles impliquent des équipes externes. Elles documentent ce qui se passe aux limites du système, pas uniquement dans les situations standards.

Chaque année, la DGFiP traite les déclarations fiscales de plusieurs dizaines de millions de contribuables. C'est précisément dans ce type de contexte que Titagone intervient. Lorsqu'on les interroge sur la manière dont ils assurent la qualité du logiciel à une telle échelle, leur réponse n'est pas qu'ils font simplement confiance à leurs développeurs, mais qu'ils s'appuient sur des processus de vérification indépendants, appliqués de façon systématique.

La confiance aveugle n'a pas sa place dans les systèmes critiques.

Il ne s'agit pas d'élitisme : à un moment de leur histoire, ces organisations ont payé le prix d'un système mal vérifié, et elles ont choisi de ne plus jamais répéter cette erreur.

Par où commencer pour évaluer la fiabilité de vos systèmes critiques

Avant toute considération technique, commencez par identifier vos systèmes les plus critiques. Même une estimation approximative suffit, l'important est de savoir pour lesquels une interruption de 24 heures poserait de vrais problèmes. Pour chaque cas : qui l'a développé, qui le maintient aujourd'hui, et quand il a été testé de façon indépendante pour la dernière fois.

La majorité des organisations n'ont pas mis à jour cette liste. Parfois, elle n'est présente que dans l'esprit d'une seule personne, ce qui constitue déjà une donnée significative concernant votre degré de risque logiciel.

Par la suite, il s'agit de trouver la personne appropriée avec qui communiquer. Une personne capable d'examiner votre situation de manière objective, sans préjugé, et de vous indiquer clairement ce qui nécessite une attention prioritaire et ce qui peut être traité ultérieurement. Il ne s'agit pas de tout reprendre dans le détail, mais simplement de se faire une vue d'ensemble de votre situation actuelle.

Chez Titagone, nous accompagnons les entreprises pour réaliser cette évaluation de manière claire et pragmatique, sans alarmisme ni refonte inutile.

Questions fréquentes

Qu'est-ce que la fiabilité logicielle précisément ?

En d'autres termes : c'est l'aptitude d'un programme à agir comme prévu, même face à des circonstances imprévues. Dans les contextes critiques, cela englobe également la manière dont il tombe en panne proprement, avec un mode dégradé documenté, plutôt que de manière chaotique et silencieuse.

Quel est le coût réel d'une défaillance logicielle au sein d'une entreprise ?

Bien que cela puisse varier d'un domaine à l'autre, les coûts finissent presque toujours par excéder ceux qui auraient été évités par la prévention. Dans le domaine de la finance, quelques minutes d'arrêt sur une plateforme de trading peuvent entraîner des pertes substantielles. Dans le domaine public, il s'agit de garantir la continuité des services pour des millions d'individus. Dans le secteur industriel, c'est la ligne de production qui est interrompue. Et au-delà des simples statistiques : l'image de marque, les autorités de régulation, les clients qui ne réitèrent pas leur visite.

Comment juger la fiabilité de ses logiciels sans avoir de compétences techniques ?

En posant trois questions simples à vos équipes : vos systèmes critiques sont-ils testés par des personnes indépendantes de celles qui les ont développés ? Quand a eu lieu le dernier audit ? Et que se passe-t-il précisément si ce système s'arrête ? Si les réponses sont floues ou évasives, vous avez déjà une réponse.

La fiabilité des logiciels et la cybersécurité, est-ce identique ?

Non, bien qu'il soit fréquent de les confondre. La cybersécurité s'occupe des menaces externes : attaques, intrusions et vols de données. La fiabilité logicielle concerne le comportement interne du logiciel, indépendamment de toute menace. Un système peut être fortement sécurisé face aux cyberattaques tout en restant totalement fragile de l'intérieur. Les deux sujets sont complémentaires. Négliger l'un ou l'autre équivaut à garder une porte ouverte.

Du code embarqué chez Thales. Zéro marge d'erreur.

Thales nous a lancé un défi ambitieux : garantir le comportement d'un code C critique face à des milliers de scénarios que personne n'aurait imaginé. Pour y répondre, nous avons créé SeaCoral, un outil capable de générer automatiquement ces tests, désormais intégrables directement dans leur chaîne de développement.

Les systèmes sont vérifiés et testés en profondeur grâce aux différents critères de couverture, pas simplement testés en surface. Si vous travaillez sur des systèmes où la moindre défaillance est inacceptable, ce projet vous parlera. Découvrez le projet.