Correctness, confidence, and context: Framing software assurance in the AI age

Le grand puzzle du logiciel : Pourquoi la « perfection » n'est pas l'objectif

Imaginez que vous construisez un château géant et invisible fait de logique et d'instructions. C'est ce que les ingénieurs logiciels font chaque jour. Ils écrivent du code pour permettre aux ordinateurs de faire des choses, de commander une pizza à piloter des avions. Pendant longtemps, le rêve était de construire ces châteaux si parfaitement qu'ils ne pourraient jamais, absolument jamais, commettre d'erreur. Les ingénieurs voulaun prouver mathématiquement que chaque brique était à sa place. Mais voici le problème : le monde réel est désordonné. Il est rempli de règles tacites, d'habitudes culturelles et de « bon sens » que l'on ne peut pas inscrire dans une liste d'instructions.

Maintenant, imaginez qu'un nouveau genre d'assistant soit arrivé : l'Intelligence Artificielle (IA). Cette IA est incroyablement douée pour deviner ce qui vient ensuite, comme un devineur super rapide qui aurait lu presque tous les livres jamais écrits. Mais contrairement aux ingénieurs de la vieille école qui voulaient prouver les choses, cette IA travaille sur des probabilités. Elle dit : « Je suis sûre à 90 % que c'est la bonne réponse », plutôt que « Je sais par fait que c'est la bonne réponse ». Cela crée un gros problème : comment pouvons-nous faire confiance à un système construit sur des suppositions alors que nous avons besoin de sécurité ? C'est ce puzzle que Mary Shaw tente de résoudre. Elle veut changer notre façon de concevoir la « correction » du logiciel, en s'éloignant du rêve impossible de la perfection pour tendre vers une approche plus pratique et d'ingénieur : s'assurer que les choses sont « assez bonnes » pour la tâche qu'elles doivent accomplir.

---

L'idée majeure du document : De la « perfection » au « assez bon »

Dans cette présentation d'ouverture destinée aux ingénieurs logiciels, Mary Shaw soutient que nous devons arrêter d'essayer de prouver que notre logiciel est 100 % parfait et commencer à nous concentrer sur le fait qu'il soit adapté à son usage. Elle suggère que l'ancienne façon de penser — essayer d'écrire un ensemble de règles parfaites pour prouver qu'un programme est correct — est brisée, surtout maintenant que nous utilisons l'IA.

Voici l'histoire de son argument, décomposée en parties simples :

1. Le problème de l'ombre : Ce que l'IA ne peut pas voir

Imaginez que vous essayiez de décrire un objet complexe, comme une tasse en papier pliable, à un ami qui n'en a jamais vu. Vous ne pouvez que lui montrer les ombres qu'elle projette sur un mur. De face, l'ombre ressemble à un carré. De côté, elle ressemble à un triangle. Par le haut, elle ressemble à un cercle. Si vous n'aviez que les ombres, vous pourriez deviner qu'il s'agit d'un bloc étrange, mais vous manqueriez le fait que c'est une tasse capable de contenir de l'eau.

Shaw dit que les modèles d'IA sont comme cet ami regardant des ombres. Ils sont entraînés sur des « ombres numériques » : le texte, le code et les données qui existent en ligne. Mais le monde réel est rempli de connaissances tacites : des choses que nous savons mais que nous n'écrivons pas. Cela inclut l'« ambiance » d'un lieu de travail, les règles non écrites d'une culture, ou le pressentiment d'un mécanicien expérimenté lorsqu'il entend un bruit étrange dans un moteur. Parce que cette connaissance n'est pas écrite, l'IA ne peut pas la voir. Elle ne voit que l'ombre, pas l'objet réel. Lorsque l'IA essaie de construire des logiciels, elle peut manquer ces détails invisibles mais cruciaux, menant à des erreurs qu'un expert humain aurait immédiatement détectées.

2. Le « culte du cargo » du codage

Shaw raconte l'histoire de populations sur des îles qui ont vu des avions atterrir avec de la nourriture pendant une guerre. Quand la guerre s'est terminée et que les avions ont cessé de venir, les habitants ont construit des tours de contrôle en bambou et ont défilé en formation, espérant faire revenir les avions. Ils ont copié les ombres de l'activité (les défilés, les tours) mais ont manqué la cause réelle (la logistique et la planification militaire).

Elle avertit que l'utilisation de l'IA pour écrire du code peut parfois devenir un « culte du cargo ». Nous pourrions demander à l'IA d'écrire du code qui semble correct (l'ombre) sans comprendre les raisons profondes de l'existence de ce code (pourquoi il doit être ainsi). Si nous nous contentons de faire du « vibe coding » (écrire du code basé sur un ressenti ou une simple instruction) sans comprendre les règles cachées, nous pourrions construire des systèmes qui ont l'air fonctionnels mais qui s'effondrent face aux problèmes du monde réel.

3. Les « titres de compétences » plutôt que les « spécifications »

Traditionnellement, les ingénieurs tentent d'écrire une « spécification » parfaite — un livre de règles géant et rigide qui dicte exactement ce que le logiciel doit faire. Shaw suggère que cela est impossible car le monde change et nous ne pouvons pas tout prédire.

Au lieu de cela, elle propose de traiter le logiciel comme une personne postulant pour un emploi. Nous n'avons pas besoin de toute son histoire de vie ; nous avons juste besoin de ses titres de compétences (credentials).

• Un plongeur montre une carte disant : « Je peux plonger à 30 mètres ».
• Un pilote montre une licence disant : « Je peux piloter cet avion ».
• Un système logiciel devrait montrer un « titre de compétence » disant : « J'ai 90 % de confiance pour gérer 1 000 utilisateurs », ou « J'ai été testé pour être sûr de moi pour cette tâche spécifique ».

Ces titres de compétences ne sont pas des preuves parfaites ; ce sont des déclarations honnêtes sur notre niveau de confiance, l'origine de cette confiance et ses limites. C'est une façon de dire : « Nous avons vérifié cela, et voici notre degré de certitude ».

4. Le choix de l'ingénieur : Le « satisficing »

Le document suggère que nous devrions cesser de viser la perfection et commencer à pratiquer le « satisficing » (le satisfaisant). C'est un mot savant pour dire « trouver une solution qui est assez bonne ».

• Si vous construisez un jeu, vous n'avez peut-être pas besoin d'une perfection de 100 %. Quelques bugs sont acceptables si le jeu est amusant et peu coûteux à produire.
• Si vous construisez un dispositif médical, vous avez besoin d'un niveau de confiance beaucoup plus élevé.

Shaw soutient que les ingénieurs doivent agir comme de vrais ingénieurs : ils doivent examiner le coût, le risque et l'usage, puis choisir le bon mélange d'outils pour accomplir la tâche. Parfois, il est moins coûteux de réparer un problème après qu'il soit survenu que d'essayer de l'empêcher de se produire un jour. L'objectif n'est pas d'éliminer toutes les erreurs (ce qui est impossible), mais de gérer le risque pour que le système soit sûr et utile pour sa mission spécifique.

Ce que cela signifie pour l'avenir

Mary Shaw ne dit pas que l'IA est mauvaise. Elle dit que nous ne pouvons pas traiter l'IA comme une baguette magique qui résout tout. Nous devons être plus intelligents dans notre utilisation. Nous devons accepter que l'IA travaille sur des suppositions (statistiques) et qu'elle ne peut pas voir les « ombres » invisibles de la culture humaine et de l'expérience.

Son message principal est un appel à l'action pour la communauté du logiciel : Arrêtons de prétendre que nous pouvons prouver que tout est parfait. Soyons plutôt des ingénieurs honnêtes. Construisons des systèmes où nous savons exactement ce dont nous sommes sûrs, ce qui ne l'est pas, et pourquoi. En faisant cela, nous pouvons utiliser l'IA pour nous aider à construire de meilleurs logiciels, sans tomber dans le piège de croire que nous avons résolu l'insoluble.

En résumé, le document suggère que l'avenir du logiciel ne réside pas dans le fait d'être « correct » au sens mathématique du terme. Il s'agit d'être adapté à son usage, de connaître ses limites et de faire des choix intelligents et rentables pour maintenir notre monde numérique en toute sécurité.