🤖 AI

Causal Software Engineering: A Vision and Roadmap

Ce papier propose l'« ingénierie logicielle causale » comme nouveau paradigme qui va au-delà de l'IA corrélative pour appliquer systématiquement des modèles et un raisonnement causaux à la prise de décision à haut risque, offrant une feuille de route pour des outils, des flux de travail et des benchmarks afin de répondre à des questions critiques de type « que se passerait-il si » tout au long du cycle de vie du logiciel.

Auteurs originaux : Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

Publié 2026-05-06

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Roberto Pietrantuono, Luca Giamattei, Stefano Russo, Julien Siebert, Neil Walkinshaw

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous êtes le capitaine d'un vaisseau spatial massif et de haute technologie. Chaque jour, vous devez prendre des décisions cruciales : Dois-je modifier les paramètres du moteur ? Dois-je rediriger le vaisseau vers un nouveau système stellaire ? Si je ralentis le rythme de travail de l'équipage, arriverons-nous plus vite ou plus lentement ?

Actuellement, la plupart des ingénieurs en logiciel (les capitaines du monde numérique) s'appuient sur une carte qui ne montre que des corrélations. C'est comme consulter un bulletin météorologique indiquant : « Chaque fois qu'il pleut, les gens portent des parapluies. » La carte vous dit que la pluie et les parapluies se produisent ensemble. Mais elle ne vous dit pas ce qui se passerait si vous arrêtiez la pluie, ou si vous obligeiez tout le monde à porter un parapluie par une journée ensoleillée.

Ce document, « Ingénierie Logicielle Causale », propose une nouvelle façon de naviguer. Il suggère d'arrêter de simplement observer ce qui se produit ensemble et de commencer à comprendre le lien de cause à effet.

Voici la vision décomposée en concepts simples :

1. Le Problème : Le Piège de la « Coïncidence »

Les auteurs racontent l'histoire d'une équipe logicielle qui a corrigé un programme informatique lent. Ils ont modifié un paramètre (appelons-le le « Bouton de Nouvelle Tentative »), et soudain, le programme est devenu plus rapide. L'équipe a célébré, pensant que le bouton était le héros.

Mais voici le piège : exactement au même moment, le système automatique de l'ordinateur a ajouté plus de travailleurs (serveurs) et le trafic des utilisateurs s'est déplacé vers un autre endroit. Le programme est devenu plus rapide à cause de toutes ces choses se produisant simultanément, et pas seulement à cause du bouton.

Parce que l'équipe n'a regardé que ce qui s'est produit ensemble (corrélation), elle a pensé que le bouton était le remède magique. Plus tard, lorsqu'ils ont essayé d'utiliser ce même bouton sur un système différent sans les travailleurs supplémentaires, le programme a planté. Ils avaient pris une coïncidence pour une cause.

2. La Solution : La Machine « Et Si »

Le document propose l'Ingénierie Logicielle Causale (ISC). Au lieu de simplement demander : « Que se passe-t-il habituellement avec X ? », l'ISC demande : « Que va-t-il se passer si nous faisons X ? »

Pensez-y comme à un simulateur de vol pour les décisions logicielles.

Ancienne méthode (Corrélation) : « Chaque fois que nous traversons une tempête, l'avion tremble. Donc, si nous traversons une tempête, nous devrions nous attendre à des tremblements. »
Nouvelle méthode (Causalité) : « Si nous modifions la poussée du moteur (l'intervention), comment les tremblements changeront-ils, même si la tempête est toujours là ? Et si nous avions modifié la poussée hier, aurions-nous évité l'accident ? »

3. Les Trois Nouveaux Outils

Pour que cela fonctionne, les auteurs suggèrent trois nouveaux outils que les ingénieurs utiliseraient, comme une liste de contrôle pour pilote :

La « Spécification de Conception Causale » (Le Plan) : Avant de faire un changement, les ingénieurs écrivent une carte simple. Ils listent :
- Ce que nous changeons (l'intervention).
- Ce que nous voulons que cela produise (l'objectif).
- Ce d'autre pourrait tout gâcher (les « facteurs de confusion », comme les déplacements de trafic ou d'autres mises à jour).
- Analogie : C'est comme un chef écrivant une recette qui indique explicitement : « Si j'ajoute du sel, je dois aussi vérifier si la température du four a changé, sinon je ne peux pas être sûr que le sel a amélioré le goût de la soupe. »
Le « Journal d'Intervention » (La Boîte Noire) : Chaque fois qu'un changement est effectué, le système enregistre non seulement ce qui a changé, mais ce qui se passait d'autre à ce moment précis.
- Analogie : Au lieu de simplement dire « Le moteur a été réparé », le journal indique : « Le moteur a été réparé, mais en même temps, la pression du carburant a chuté et la vitesse du vent a augmenté. » Cela aide à séparer la vraie cause du bruit de fond.
Le « Modèle Vivant » (La Boule de Cristal) : C'est un système intelligent qui utilise les plans et les journaux pour prédire l'avenir. Il ne se contente pas de deviner ; il calcule la « cause » en ignorant le « bruit ».
- Analogie : C'est comme un GPS qui ne vous montre pas seulement où se trouve le trafic, mais qui vous dit : « Si vous prenez cette déviation, vous gagnerez 10 minutes, même si la route principale est actuellement libre. »

4. La Feuille de Route : Une Ascension en Quatre Étapes

Les auteurs ne s'attendent pas à ce que cela se produise du jour au lendemain. Ils proposent une feuille de route en quatre étapes, comme l'ascension d'une montagne :

Niveau 1 : Voir Clair (Observabilité Causale) : Nous devons construire de meilleurs capteurs qui ne se contentent pas d'enregistrer des données, mais comprennent la structure de la façon dont les choses sont connectées. Nous devons savoir quels fils sont réellement connectés au moteur, et pas seulement lesquels vibrent.
Niveau 2 : Expérimentation Sûre (Interventionnabilité par Conception) : Nous devons effectuer des changements par petites étapes sûres (comme tester un nouveau moteur sur une seule aile de l'avion) afin d'être sûrs de ce qui a causé le résultat.
Niveau 3 : Voyage dans le Temps (Assurance Contrefactuelle) : Nous avons besoin d'outils capables de répondre : « Si nous avions fait les choses différemment hier, l'accident aurait-il été évité ? » Cela nous aide à apprendre de nos erreurs sans avoir à faire s'écraser l'avion à nouveau.
Niveau 4 : Le Copilote de Confiance (Copilotes Causaux) : Enfin, nous obtenons des assistants IA qui ne se contentent pas de deviner. Ils sont « gouvernés » par les règles de cause à effet. Ils ne vous diront pas d'appuyer sur un bouton à moins d'être sûrs que cela résoudra réellement le problème, et ils admettront quand ils n'ont pas assez de données pour être sûrs.

5. Comment Savoir que Cela Fonctionne ?

Le document suggère que nous devons tester ces nouveaux outils avec des « examens » spécifiques :

Le Test « Est-ce que ça a marché ? » : Donnez à l'ordinateur un changement connu et voyez s'il identifie correctement le résultat.
Le Test « Et Si ? » : Donnez à l'ordinateur un désastre passé et demandez : « Cela aurait-il été évité si nous avions fait X ? » Voyez si sa réponse correspond à l'histoire réelle.
Le Test de « Stress » : Essayez de tromper le système avec de fausses données pour voir s'il admet : « Je ne peux pas être sûr », plutôt que de faire une supposition confiante mais erronée.

La Conclusion

Le document soutient que l'ingénierie logicielle évolue du devinement basé sur les motifs vers la décision basée sur les causes. En traitant chaque mise à jour logicielle comme une expérience délibérée et en enregistrant le « pourquoi » derrière chaque résultat, nous pouvons construire des systèmes plus sûrs, plus fiables et plus faciles à réparer lorsque les choses tournent mal. Il s'agit de passer de « Il pleut habituellement quand le ciel est gris » à « Si nous allumons les arroseurs, l'herbe deviendra humide, même si le ciel est gris ».

Résumé technique : Ingénierie logicielle causale : une vision et une feuille de route

Énoncé du problème

L'ingénierie logicielle (IL) moderne repose fortement sur des outils pilotés par l'IA (détection d'anomalies, AIOps, agents basés sur les LLM) pour gérer des décisions à haut risque dans l'incertitude. Cependant, les approches actuelles reposent principalement sur des modèles corrélationnels qui identifient des motifs et des co-occurrences dans les données historiques (par exemple, « lorsque la métrique $Y$ est élevée, l'événement $E$ apparaît souvent »). Ces modèles peinent à répondre aux questions interventionnelles (« Que se passe-t-il si nous modifions un délai d'attente ? ») ou aux questions contrefactuelles (« Une panne aurait-elle été évitée avec un plan de publication différent ? »).

Le problème fondamental est que les signaux corrélationnels conduisent souvent à des conclusions fallacieuses lorsque des confondants cachés (par exemple, des événements de mise à l'échelle automatique, des changements de trafic) varient conjointement avec l'intervention. Par conséquent, les ingénieurs peuvent identifier à tort les moteurs causaux du comportement du système, ce qui entraîne des stratégies de remédiation inefficaces ou nuisibles. L'article soutient que l'IL doit passer de la « chasse aux corrélations a posteriori » à une prise de décision consciente des interventions fondée sur des hypothèses causales explicites.

Méthodologie et paradigme proposé

Les auteurs proposent l'Ingénierie Logicielle Causale (ILC) comme un nouveau paradigme intégrant des modèles et un raisonnement causaux dans les flux de travail standards de l'IL. L'ILC ne remplace pas les pratiques existantes mais les complète avec trois composants essentiels :

Hypothèses explicites : Rendre explicites et révisables les structures causales (par exemple, les liens interdits ou requis entre les variables) et les confondants.
Estimations d'effets conscientes de l'incertitude : Fournir des estimations d'effets causaux avec des bornes d'incertitude quantifiées plutôt que des prédictions ponctuelles.
Diagnostic contrefactuel : Permettre un raisonnement sur ce qui se serait produit dans des conditions différentes.

Le flux de travail de l'ILC

La méthodologie introduit un flux de travail « causal en premier » couvrant le cycle de vie du logiciel, soutenu par trois artefacts légers :

Spécifications de conception causale : Documents versionnés attachés aux exigences et aux enregistrements de décisions d'architecture (ADR) définissant les variables clés, les résultats, les confondants candidats et les interventions admissibles.
Journaux d'intervention : Enregistrements structurés des changements (déploiements, bascules de fonctionnalités) capturant l'intervention prévue ( $X$ ), les confondants simultanés ( $Z$ ) et les résultats observés, reliant les actions CI/CD à la réalité opérationnelle.
Modèles causaux vivants : Modèles d'exécution qui instancient les spécifications de conception avec des données de télémétrie en direct et des données expérimentales pour répondre aux requêtes « et si » et effectuer un diagnostic contrefactuel.

Le cadre utilise l'opérateur do ($do(X=x)$) pour distinguer l'observation d'un événement de l'intervention sur celui-ci, permettant l'estimation d'effets causaux exempts de confondants $P(Y|do(X=x))$.

Contributions clés

L'article présente une vision structurée et une feuille de route pour l'adoption de l'ILC, organisées en quatre voies co-évoluant et un modèle de maturité par étapes :

1. Quatre voies vers la préparation causale

Les auteurs définissent les progrès à travers quatre voies, chacune passant des « Réalisations » actuelles aux « Défis » et enfin aux « Rêves » :

Voie 1 : Observabilité causale (CRL-1) : Passer de l'analyse de la cause racine rétrospective à l'observabilité causale. Les défis incluent la construction de modèles conscients des confondants à partir de données de surveillance et la garantie que les graphes causaux restent stables face à l'évolution du système.
Voie 2 : Intervenable par conception (CRL-2) : Transformer les mécanismes de livraison existants (CI/CD, drapeaux de fonctionnalités, canaris) en instrumentation causale. Les défis consistent à concevoir des expériences sûres (tests canaris/A-B) garantissant l'identifiabilité et à propager l'incertitude dans les décisions de validation ou de rejet.
Voie 3 : Garantie contrefactuelle (CRL-3) : Passer du raisonnement contrefactuel local au débogage à la garantie à l'échelle du système. Les défis incluent la réalisation d'une analyse de cause racine (RCA) contrefactuelle à grande échelle et la standardisation des vérifications de réfutation (par exemple, tests placebo).
Voie 4 : Gouvernance et alignement (CRL-4/5) : Intégrer le raisonnement causal dans les cas de sécurité et la conformité. Les défis incluent la création de revendications causales auditable pour les régulateurs et le développement de « copilotes causaux » (agents LLM contraints par la cohérence causale).

2. Niveaux de préparation causale (CRL)

L'article propose un modèle de maturité (de CRL-0 à CRL-5) pour mesurer les progrès organisationnels et des outils, allant des systèmes basés sur la corrélation (CRL-0) aux copilotes causaux entièrement certifiés et à la certification causale (CRL-5).

3. Agenda d'évaluation et de référence

Pour mesurer les progrès, les auteurs proposent trois familles de références :

Références d'effet d'intervention : Jeux de données avec des changements connus et des impacts de vérité terrain pour tester l'estimation d'effets et l'étalonnage de l'incertitude.
Références d'incidents contrefactuels : Jeux de données d'incidents avec des traces versionnées pour évaluer les capacités de RCA contrefactuelle.
Références de test causal : Scénarios (par exemple, simulateurs, injection de pannes) pour évaluer si la génération de tests peut identifier des facteurs causaux plutôt que de simples corrélations.

L'article souligne que les résultats doivent rapporter des estimations d'effets avec incertitude, des analyses de sensibilité et des modes de défaillance lorsque les hypothèses sont rompues.

Résultats et affirmations

En tant qu'article de vision et de feuille de route, les auteurs ne présentent pas de résultats expérimentaux empiriques ni d'outil spécifique implémenté. Au lieu de cela, les « résultats » sont le cadre conceptuel et la feuille de route elle-même. L'article affirme :

Faisabilité : L'ILC est réalisable en complétant les artefacts existants de l'IL (spécifications, journaux, modèles) plutôt qu'en exigeant une refonte complète de la pile d'ingénierie.
Nécessité : Les outils actuels pilotés par l'IA sont insuffisants pour les décisions à haut risque car ils manquent de raisonnement causal ; l'ILC fournit la structure nécessaire pour répondre aux questions « et si » et « que se serait-il passé ».
Actionnabilité : La feuille de route proposée (Voies 1 à 4) offre un chemin concret pour les chercheurs et les praticiens afin de passer d'une ingénierie basée sur la corrélation à une ingénierie basée sur la causalité.

Importance

L'article positionne l'ILC comme une évolution critique pour l'ingénierie logicielle à une ère de systèmes complexes et adaptatifs. Son importance réside dans :

Le changement de paradigme : Déplacer le domaine de la reconnaissance de motifs vers le raisonnement causal, en abordant la limitation fondamentale de l'IA corrélationnelle dans les environnements dynamiques.
L'opérationnalisation de la causalité : Fournir une approche pratique, basée sur des artefacts (spécifications, journaux, modèles vivants) qui s'intègre dans les pipelines existants, rendant le raisonnement causal accessible aux ingénieurs en exercice.
La facilitation de la confiance : Offrir une voie vers une « garantie étayée par des preuves » où les décisions concernant la sécurité, l'équité et la fiabilité sont fondées sur des revendications causales auditable plutôt que sur des corrélations opaques.
La catalyse des efforts communautaires : Appeler à des jeux de données partagés, des pratiques d'évaluation communes et des outils causaux spécifiques à l'IL pour transformer le raisonnement causal en une pratique d'ingénierie courante.

Les auteurs concluent que l'ILC permettra la prochaine génération d'assistants de confiance, de tests contrefactuels et de garanties étayées par des preuves, transformant fondamentalement la manière dont les systèmes logiciels sont conçus, exploités et gouvernés.