Une introduction à la théorie de la résidualité

La théorie de la résidualité renouvelle la conception logicielle en modélisant les systèmes comme des résidus interconnectés, afin de traiter l’incertitude comme une donnée structurante dans les environnements métier complexes.

L’article qui suit est une transcription éditoriale d’un talk donné par Barry O’Reilly, consacré à la théorie de la résidualité (Residuality Theory), une approche récente de la conception logicielle visant à mieux outiller les architectes face à l’incertitude propre aux environnements métier complexes.

Barry O’Reilly est fondateur de Black Tulip Technology. Il a occupé plusieurs postes de premier plan chez Microsoft, notamment ceux de Chief Architect et d’Azure Architect pour l’Europe de l’Ouest. Il a également été Worldwide Lead de la communauté Solutions Architecture chez Microsoft et fondateur du Swedish Azure User Group. Ses travaux actuels s’inscrivent dans le cadre d’un doctorat portant sur la conception logicielle et les sciences de la complexité.

Le texte que vous allez lire n’est ni un résumé, ni une interprétation personnelle, mais une tentative de mise à l’écrit fidèle du raisonnement développé oralement dans le talk. Il ne s’agit pas non plus d’un verbatim : le contenu a été réorganisé, reformulé et structuré pour être lu, tout en conservant l’intégralité des idées, des arguments et des exemples pertinents.

Cette démarche répond à plusieurs objectifs. D’une part, proposer une version française d’un contenu dense initialement présenté à l’oral en anglais. D’autre part, offrir une alternative au format vidéo, plus adaptée à une lecture approfondie, à la relecture et au travail conceptuel. Enfin, permettre un gain de temps pour celles et ceux qui assimilent plus efficacement des raisonnements complexes à l’écrit qu’à l’oral.

La vidéo du talk original est référencée en bas de l’article, et sa consultation est vivement recommandée pour bénéficier du contexte, du rythme et des nuances propres à la présentation orale.

Cette restitution écrite repose sur ma compréhension du talk ; toute éventuelle approximation ou interprétation maladroite m’en revient entièrement, et ne reflète pas nécessairement la pensée de l’auteur.

Pourquoi l’architecture logicielle est-elle si difficile ?

Ordre, désordre et hyperliminalité des systèmes logiciels

L’architecture logicielle est unanimement reconnue comme une discipline difficile. Ce constat ne vient pas seulement des développeurs débutants ou des équipes en difficulté, mais des architectes les plus expérimentés, des décideurs techniques et des praticiens seniors. Lorsqu’on les interroge sur la manière dont ils prennent leurs décisions structurantes — nombre de composants, répartition des responsabilités, découpage fonctionnel — la réponse est étonnamment homogène : ils ne savent pas formellement expliquer comment ils décident.

Les choix architecturaux reposent sur l’intuition, l’expérience accumulée, des habitudes forgées au fil des projets, parfois sur l’influence d’un article ou d’un livre récent. Il n’existe pas de méthode claire, objectivable, permettant de dire : dans cette situation, cette structure est la bonne. Cette absence de fondement explicite n’est pas marginale : elle est structurelle.

Pour comprendre pourquoi, il faut commencer par examiner la nature même des systèmes avec lesquels les ingénieurs logiciels travaillent.

Systèmes ordonnés : le confort de la prédictibilité

Certains systèmes sont fondamentalement ordonnés. Ils sont fortement contraints, obéissent à des règles claires et déterministes, et leurs états futurs peuvent être prédits à partir de leurs états présents. Lorsqu’on les teste, ils réagissent de manière répétable : un même test produit le même résultat, encore et encore.

Le logiciel, pris isolément, appartient à cette catégorie. Il est mécanique, logique, déterministe. Une instruction produit toujours le même effet dans les mêmes conditions. Les compétences fondamentales de l’ingénierie logicielle — modélisation, algorithmes, tests, vérification, optimisation — sont précisément conçues pour traiter ce type de systèmes.

C’est un terrain familier. Les ingénieurs sont formés à penser en termes de causalité, de preuve, de complexité algorithmique, de correction formelle ou empirique. Dans cet univers, la notion de bonne solution a un sens.

Systèmes désordonnés : l’imprévisibilité radicale

À l’opposé, certains systèmes sont désordonnés. Ils sont faiblement contraints, sensibles à des influences multiples, et leur comportement n’est ni prédictible ni stable. Les systèmes humains, sociaux, économiques ou organisationnels entrent dans cette catégorie.

Dans ces systèmes :

les mêmes actions ne produisent pas toujours les mêmes effets,
l’acte d’observer ou de mesurer modifie parfois le comportement observé,
des patterns peuvent apparaître puis disparaître,
ou pire, être perçus là où il n’y en a pas.

Tester un tel système ne garantit rien : le test suivant peut donner un résultat différent, non parce que le système est « cassé », mais parce qu’il a évolué.

Ces systèmes exigent un mode de pensée radicalement différent de celui mobilisé pour les systèmes ordonnés. Pourtant, ce mode de pensée est rarement enseigné aux ingénieurs.

Le choc des deux mondes

Le cœur du problème architectural apparaît précisément à l’interface entre ces deux types de systèmes.

L’ingénieur logiciel conçoit un artefact ordonné — un système logiciel — en mobilisant des outils parfaitement adaptés à un monde déterministe. Il construit une structure, la teste, la valide, et en maîtrise les propriétés internes. À ce stade, tout fonctionne.

Puis cet artefact est déployé dans un environnement profondément désordonné :
des utilisateurs, des organisations, des marchés, des contraintes économiques, des dynamiques sociales, parfois politiques ou géopolitiques. Cet environnement est instable, imprévisible, et largement incompréhensible dans sa globalité.

Le logiciel, aussi rigoureux soit-il, n’échappe pas à cette immersion. Il devient un élément d’un système bien plus vaste, dont le comportement ne peut être ni anticipé ni contrôlé.

Le rôle impossible de l’architecte

L’architecte logiciel se retrouve alors dans une position singulière. Il doit simultanément :

raisonner avec des outils d’ingénierie ordonnée,
et composer avec des réalités humaines désordonnées.

Il commence dans le monde de l’ordre : modélisation, composants, dépendances, performances, tests... Puis il est contraint d’en sortir pour affronter les attentes des utilisateurs, les décisions managériales, les contraintes organisationnelles, les pressions du marché... Puis il doit revenir au monde technique pour ajuster la structure...

Ce va-et-vient est permanent. L’architecte n’est jamais pleinement dans l’un des deux mondes. Il évolue dans un espace intermédiaire, instable, où les règles changent selon le point de vue adopté.

Cet espace intermédiaire est un espace liminal. Les systèmes logiciels réels sont donc des systèmes hyperliminaux : ils existent dans le couloir entre deux régimes de réalité incompatibles.

L’erreur de transposition

Les difficultés apparaissent dès que l’on tente d’appliquer les outils d’un monde à l’autre.

Utiliser des modèles UML pour décrire des organisations humaines, par exemple, conduit rapidement à des absurdités. Les relations humaines, les jeux de pouvoir, les motivations implicites ne se laissent pas réduire à des diagrammes de classes ou de séquence.

Inversement, traiter un système logiciel comme s’il était fondamentalement désordonné conduit à renoncer à toute rigueur technique.

Le problème n’est pas l’existence de ces deux mondes, mais la nécessité constante de passer de l’un à l’autre sans outil conceptuel adapté à cette transition.

Le problème de X

Lorsque l’on place un système logiciel dans son environnement réel, un phénomène inévitable se produit : quelque chose d’imprévu survient.

Un événement, une contrainte, une interaction, une série de circonstances qui n’avaient pas été anticipées. Appelons cet événement X.

X n’est pas une anomalie exceptionnelle. Il n’est pas le signe d’une mauvaise analyse ou d’une incompétence. Il est inhérent au fonctionnement des systèmes complexes.

X n’apparaît jamais seul. Il émerge d’un enchevêtrement de facteurs — humains, organisationnels, économiques, sociaux — dont aucun ne peut être isolé proprement.

Lorsque X survient, la structure logicielle conçue initialement se révèle inadaptée. Ce qui fonctionnait à un instant t₁ ne fonctionne plus à t₂. Le système « casse », ou du moins cesse de remplir correctement sa fonction.

La réponse habituelle consiste alors à reconstruire ou à adapter la structure.

La réduction artificielle de l’incertitude

Face à cette situation, les ingénieurs cherchent naturellement à réduire la complexité à quelque chose de gérable. Ils tentent de contracter l’environnement désordonné en un ensemble fini d’éléments maîtrisables.

C’est le rôle que prétendent jouer des pratiques comme :

l’ingénierie des exigences,
la gestion des risques.

On demande aux parties prenantes de décrire l’avenir.
On attribue des probabilités chiffrées à des événements hypothétiques.
On produit des documents qui donnent l’illusion d’une maîtrise rationnelle.

Mais ces probabilités n’ont souvent aucun fondement empirique réel. Elles servent avant tout à rassurer. Elles réduisent artificiellement l’espace des possibles, au prix d’une perte de lucidité.

Lorsque le système est finalement déployé, un nouvel X apparaît — toujours imprévisible — et la structure échoue à nouveau.

Pourquoi certains architectes réussissent-ils malgré tout ?

Si cette description était complète, l’architecture logicielle serait une entreprise vaine. Il faudrait renoncer à toute tentative de structuration, attendre que les problèmes surviennent et réagir au coup par coup.

Or ce n’est pas ce que l’on observe. Certains architectes, de manière répétée, conçoivent des systèmes qui résistent mieux que d’autres à l’imprévu. Leur réussite n’est ni sporadique ni aléatoire. Si c’était une question de chance, on observerait une distribution uniforme des succès. Or ce n’est pas le cas. Une minorité de praticiens réussit de façon disproportionnée.

Ils font donc quelque chose de différent.

Rationalité technique et pratique réflexive

Pour comprendre cette différence, il est utile de se tourner vers les travaux sur la pratique professionnelle. Dès le début des années 1980, une distinction fondamentale a été formulée entre :

la rationalité technique, adaptée aux systèmes ordonnés,
et la pratique réflexive, nécessaire dans les domaines complexes et incertains.

La rationalité technique applique des règles connues à des problèmes bien définis.
La pratique réflexive accepte l’ambiguïté, l’incertitude, et apprend en agissant.

L’industrie logicielle, incapable de formaliser cette compétence, a adopté une stratégie implicite : prendre des développeurs jugés compétents, les propulser dans des rôles d’architecte, puis observer s’ils survivent.

Après quelques années :

s’ils tiennent, ils sont reconnus comme architectes,
s’ils échouent, on recommence avec quelqu’un d’autre.

Ce mécanisme de sélection est coûteux, lent et brutal. Il ne constitue pas une méthode de formation, mais un filtre.

Le vrai problème : l’incertitude irréductible

Le problème fondamental de l’architecture logicielle n’est donc ni la technique, ni le manque d’outils, ni même la complexité au sens courant. C’est l’incertitude irréductible liée au caractère hyperliminal des systèmes logiciels.

On ne sait pas ce qui va se passer.
On ne peut pas le prédire.
On ne peut pas le contrôler.

Toute méthode qui prétend le contraire repose sur une illusion.

C’est à partir de cette reconnaissance — inconfortable mais nécessaire — que la théorie de la résidualité commence.

De l’incertitude aux attracteurs

Résidualité, simulation aléatoire et réseaux complexes

La reconnaissance de l’incertitude irréductible ne constitue pas une conclusion pessimiste. Elle est, au contraire, le point de départ nécessaire pour toute approche rigoureuse de l’architecture logicielle. Tant que l’on tente de nier cette incertitude — en la masquant derrière des exigences, des probabilités ou des plans — on se prive de toute prise réelle sur le système.

Le problème n’est donc pas d’éliminer l’incertitude, mais de raisonner correctement en sa présence.

L’incertitude comme donnée première

Dans un système hyperliminal, l’architecte ne connaît ni :

l’ensemble des forces en présence,
ni leurs interactions,
ni les événements à venir,
ni les effets de ces événements sur le système.

Ce constat est souvent perçu comme un aveu d’échec. Pourtant, il est d’une honnêteté intellectuelle minimale. Toute méthode qui prétend faire mieux tombe nécessairement dans la fiction.

Face à cette situation, une question centrale émerge :

Comment agir rationnellement lorsque l’on ne connaît ni le problème exact, ni les événements à venir, ni les critères de succès futurs ?

Cette question n’est pas propre au logiciel. Elle traverse l’ensemble des sciences de la complexité.

Le détour par les sciences de la complexité

Les sciences de la complexité se sont développées précisément pour traiter ce type de problèmes : des systèmes composés de nombreux éléments interconnectés, dont le comportement global ne peut être déduit simplement de celui des parties.

Elles ont produit une quantité considérable de concepts, de modèles et de résultats mathématiques. Cependant, pour un ingénieur logiciel, ces travaux sont souvent frustrants. Ils sont intellectuellement stimulants, mais rarement actionnables.

On y parle de réseaux, d’émergence, de chaos, de probabilités étranges, de comportements non linéaires — sans jamais arriver à une question simple :
que dois-je faire, concrètement, lorsque je conçois un système logiciel ?

La théorie de la résidualité s’inscrit dans cette filiation, mais avec une contrainte forte : rester applicable à l’ingénierie logicielle.

Le résidu : ce qui reste quand le système casse

Considérons à nouveau un système complexe — par exemple un système métier — dans lequel est inséré un artefact logiciel. Ce système est constitué d’un grand nombre de nœuds interconnectés : personnes, processus, règles, outils, contraintes externes.

Nous ne savons pas précisément comment ce système fonctionne.
Nous ne voyons pas tous les nœuds.
Nous ne connaissons pas toutes les relations.

La seule chose que nous pouvons affirmer avec certitude est la suivante : quelque chose va se produire.

Lorsque cet événement imprévu survient, le système change. Dans le langage courant de l’ingénierie, on dira que le système est « cassé » : il ne se comporte plus comme avant, il ne produit plus les mêmes résultats.

Ce qui subsiste après cette rupture — la partie du système qui continue d’exister, même de manière dégradée — constitue ce que la théorie appelle le résidu.

Le résidu n’est ni une erreur ni un dysfonctionnement ; il est la trace structurelle laissée par un événement imprévu, et le socle sur lequel le système continuera d’évoluer.

Le futur comme fonction du résidu

La proposition centrale de la théorie de la résidualité est la suivante :

Le futur du système sera construit à partir du résidu.

Nous ne savons pas :

quel sera l’événement déclencheur,
ni quelle forme prendra le futur système.

Mais nous savons que ce futur ne surgira pas ex nihilo. Il émergera à partir de ce qui aura survécu.

Autrement dit, même dans un système que nous ne comprenons pas, il existe un point d’entrée pour l’ingénierie : la manière dont les choses se désagrègent.

C’est ici que le raisonnement diverge fortement de nombreuses approches issues des sciences de la complexité : le système n’a pas d’intention, il n’a pas de finalité, il ne « veut » rien. Il se transforme simplement lorsqu’il est soumis à des contraintes imprévues.

L’ingénieur face à l’ignorance

Pris isolément, ce raisonnement peut sembler désespérant. Nous avons :

un système que nous ne comprenons pas,
des événements imprévisibles,
un futur indéterminé.

Que peut bien faire un ingénieur dans un tel contexte ?

La réponse tient dans une distinction essentielle : si nous ne contrôlons pas le système global, nous contrôlons encore l’artefact logiciel, qui est un système ordonné. C’est à ce niveau — et uniquement à ce niveau — que l’ingénierie conserve toute sa puissance.

La simulation aléatoire : accepter l’ignorance

Pour comprendre comment agir sans connaissance exhaustive, il est utile de se tourner vers une technique classique des statistiques : la simulation aléatoire.

Imaginons une situation simple : un carré de côté x, à l’intérieur duquel se trouve un cercle dont on ignore la position exacte. Comment estimer l’aire du cercle sans mesurer ses dimensions ?

Une méthode consiste à lancer des points aléatoirement dans le carré :

chaque point qui tombe dans le cercle constitue une donnée,
chaque point à l’extérieur en est une autre.

Au bout d’un grand nombre de lancers, la proportion de points dans le cercle permet d’estimer son aire, sans jamais avoir utilisé de règle. Cette estimation est imparfaite, mais scientifiquement raisonnable. Et plus le nombre d’échantillons augmente, plus l’estimation devient précise.

Ce qui est crucial ici, c’est que :

les points sont choisis aléatoirement,
sans connaissance préalable de la position du cercle.

Exigences et risques comme échantillons aléatoires

Dans un environnement hyperliminal, les exigences et les risques jouent exactement ce rôle. Ils ne sont pas des vérités, ils ne sont pas exhaustifs et ils ne sont pas nécessairement représentatifs : ils sont des échantillons de la réalité.

Les traiter comme des fondations solides revient à se mentir à soi-même. Leur seule valeur réside dans le fait qu’ils constituent quelques points dans un espace que l’on ne peut pas cartographier complètement.

Le problème des pratiques classiques n’est donc pas qu’elles soient imparfaites, mais qu’elles prétendent éliminer le hasard, là où il est inévitable.

Les réseaux de Kauffman : de l’explosion à la contrainte

Pour aller plus loin, il faut introduire un concept clé issu des sciences de la complexité : les réseaux de Kauffman.

Ces travaux sont dus au biologiste et théoricien de la complexité Stuart Kauffman, qui cherchait à comprendre comment la vie pouvait émerger à partir de systèmes chimiques apparemment chaotiques.

Un réseau de Kauffman est un réseau booléen aléatoire :

chaque nœud possède deux états possibles (par exemple, allumé ou éteint),
chaque nœud exécute une fonction interne qui détermine son état,
initialement, ces fonctions sont indépendantes.

Dans un réseau de n nœuds, le nombre d’états possibles est de 2ⁿ.
Pour n = 100 000, ce nombre dépasse celui des atomes dans l’univers observable.

À première vue, un tel système semble totalement ingérable.

L’émergence des attracteurs

Kauffman a ensuite introduit une modification essentielle : il a connecté les nœuds entre eux, de sorte que l’état de chacun dépende partiellement de celui des autres.

Contre toute attente, le comportement global du système s’est simplifié. Au lieu d’explorer l’ensemble de l’espace des états possibles, le réseau converge vers un nombre très limité de configurations stables, appelées attracteurs.

Pour un réseau de 100 000 nœuds connectés, le nombre d’attracteurs observés est de l’ordre de √n — soit quelques centaines seulement.

Ces attracteurs représentent des patterns de comportement vers lesquels le système revient sans cesse, malgré la complexité de ses composants.

Ce que cela change pour l’ingénieur logiciel

Ce résultat est fondamental. Il signifie que des systèmes extrêmement complexes peuvent présenter un comportement global contraint.

Appliqué au logiciel, cela suggère que :

bien que l’environnement soit imprévisible,
le système global tend à se stabiliser dans un nombre limité de régimes de fonctionnement.

Ces régimes — les attracteurs — sont ce avec quoi l’architecture doit composer.

Il devient alors inutile de tenter de prévoir tous les scénarios possibles. Il suffit de concevoir des structures capables de survivre dans certains attracteurs clés.

NKP : une grille de lecture structurelle

Pour rendre cette idée exploitable, on introduit une abstraction simple : l’analyse NKP.

N représente le nombre de nœuds du système — en logiciel, le nombre de composants.
K représente le nombre de relations entre ces nœuds — autrement dit, le degré de couplage.
P représente le biais des nœuds — la probabilité qu’un composant adopte un comportement plutôt qu’un autre.

Lorsque :

N augmente, le système devient plus difficile à maîtriser.
K augmente, le nombre d’attracteurs croît et les transitions deviennent chaotiques.
P permet de stabiliser le système en orientant son comportement.

En ingénierie logicielle :

discuter microservices vs monolithe est une discussion sur N,
parler de couplage est une discussion sur K,
définir des contrats, des schémas, des stratégies d’erreur est une manière d’agir sur P.

Une pratique déjà existante… mais implicite

Chaque projet logiciel suit en réalité le même algorithme implicite :

une simulation approximative de l’environnement,
une analyse structurelle des composants possibles.

Le problème est que :

la simulation n’est pas réellement aléatoire,
l’analyse NKP est masquée derrière des couches de principes et de patterns.

La théorie de la résidualité propose de rendre ces deux étapes explicites, assumées et outillées.

Transition vers la pratique

À ce stade, un changement de perspective s’opère. Il ne s’agit plus de concevoir une architecture « correcte » pour un futur imaginé, mais de concevoir une architecture dont les résidus successifs permettront au système de survivre dans différents attracteurs.

La question n’est plus :

Que doit faire mon système ?

Mais :

Que doit-il rester lorsque tout ne se passe pas comme prévu ?

C’est cette logique qui va maintenant être appliquée de manière concrète.

Concevoir pour l’effondrement

Stressors, résidus et architectures survivantes

À partir du moment où l’on accepte que l’incertitude est irréductible et que le futur du système sera construit sur ce qui subsiste après une rupture, la question architecturale se reformule entièrement.

Il ne s’agit plus de concevoir un système optimal pour un scénario idéal.
Il s’agit de concevoir un système dont les restes continueront d’être exploitables lorsque l’environnement changera de manière imprévisible.

C’est ici qu’intervient la méthode centrale de la théorie de la résidualité : le travail par stressors et résidus.

Les stressors : provoquer volontairement X

Un stressor est une contrainte, un événement ou une situation qui perturbe le fonctionnement normal du système. Il peut s’agir :

d’une panne,
d’un comportement utilisateur inattendu,
d’un changement réglementaire,
d’un événement social ou économique,
ou de toute autre perturbation externe.

Dans les approches classiques, les stressors sont sélectionnés selon des critères de plausibilité, de probabilité ou de vraisemblance. C’est précisément ce que la théorie de la résidualité remet en question.

Dans un système hyperliminal, la plausibilité est un biais cognitif, pas un critère scientifique.

L’importance du non-sens apparent

Lorsque les ingénieurs tentent de « raisonner » sur les risques, ils tombent systématiquement dans ce que les sciences de la complexité appellent le piège de la haute dimensionnalité.

Face à un espace de possibilités immense, l’esprit humain :

se concentre sur ce qui lui semble central,
privilégie ce qui est cohérent avec son expérience passée,
élimine ce qui paraît absurde ou marginal.

Autrement dit, nous cessons très vite d’être aléatoires.

Des concepts comme YAGNI jouent ici un rôle central : ils codifient la décision de rester dans une zone de confort, au cœur de ce qui paraît raisonnable.
Mais dans un système complexe, les événements destructeurs viennent rarement du centre.

C’est pour cette raison que la théorie de la résidualité introduit volontairement des stressors absurdes, improbables ou grotesques.

Les « lézards » : forcer l’aléa

L’exemple emblématique utilisé consiste à imaginer qu’un jour, de gigantesques lézards cracheurs de feu émergent de la mer pour détruire la ville dans laquelle le système est déployé. Ce scénario est évidemment irréaliste. Mais c’est précisément le point.

Le stressor « lézards » n’a pas pour fonction d’être crédible. Il sert à court-circuiter la rationalisation prématurée. Il oblige l’équipe à poser une question radicalement différente :

Que resterait-il de notre système dans une situation de destruction massive ?

La réponse à cette question n’est pas spécifique aux lézards. Elle couvre implicitement :

les incendies,
les inondations,
les guerres,
les pandémies,
les crises économiques,
les mouvements sociaux,
et toute une série d’événements que personne n’osera jamais mettre dans un registre de risques.

Chaque fois qu’un stressor « ridicule » est écarté au nom du réalisme, on appauvrit la capacité du système à survivre dans son environnement réel.

Du stressor au résidu

Lorsqu’un stressor est appliqué à une architecture naïve — c’est-à-dire conçue pour un chemin heureux — une partie du système cesse de fonctionner.

C’est précisément ce qui est recherché.

On observe alors ce qui subsiste :

quelles fonctions continuent d’exister,
quelles données restent accessibles,
quels comportements demeurent possibles.

Ce reste constitue le résidu associé à ce stressor. Le travail de l’architecte consiste ensuite à se demander :

Comment puis-je modifier la structure logicielle pour que ce résidu soit plus utile, plus exploitable, plus robuste ?

Cette modification prend généralement la forme de l’ajout d’un composant, d’un mécanisme ou d’une capacité supplémentaire.

Accumuler les résidus

Un point fondamental de la méthode est que l’on ne cherche pas à produire un résidu universel. Chaque stressor génère son propre résidu. Le processus consiste à :

appliquer un stressor,
identifier le résidu,
ajuster l’architecture pour améliorer ce résidu,
recommencer avec un autre stressor.

On obtient ainsi une collection de résidus, chacun correspondant à un attracteur potentiel du système.

L’architecture finale n’est pas conçue pour un futur donné, mais comme une superposition cohérente de résidus.

Un retour sur investissement asymétrique

Pourquoi cette approche fonctionne-t-elle malgré le caractère arbitraire des stressors ? La réponse tient à la structure mathématique des systèmes complexes. Un attracteur peut être atteint par de nombreuses chaînes d’événements différentes.
Inversement, un résidu bien conçu a tendance à rester viable dans plusieurs attracteurs.

Autrement dit :

un seul stressor peut couvrir des dizaines de scénarios réels,
un seul résidu peut protéger le système contre une multitude d’événements inconnus.

C’est un levier extrêmement puissant, inaccessible aux approches classiques basées sur l’énumération exhaustive des risques.

Exemple détaillé : réseau de bornes de recharge pour véhicules électriques

Pour rendre cette méthode tangible, considérons un exemple réaliste, inspiré de plusieurs projets industriels. Décrivons une architecture naïve optimisée pour le happy path :

Un opérateur déploie un réseau de bornes de recharge pour véhicules électriques. Le fonctionnement nominal est simple :

le client arrive avec son véhicule,
il présente un badge ou un porte-clés RFID,
la borne interroge un service central,
l’abonnement est validé,
la recharge démarre.

Stressor : échec de l’authentification

Dans la pratique, les badges RFID sont sensibles :

à la température,
à l’humidité,
aux champs magnétiques,
à l’usure.

Lorsque l’authentification échoue, le résidu est le suivant :

un véhicule immobilisé,
une borne bloquée,
un client frustré, parfois agressif,
et un actif indisponible.

Ce résidu est catastrophique. Pour améliorer ce résidu, on introduit un nouveau composant : la reconnaissance automatique des plaques d’immatriculation.

En cas d’échec d’authentification :

la borne identifie le véhicule,
la recharge démarre,
la facturation est différée.

Le résidu devient :

un véhicule rechargé,
un client apaisé,
un opérateur payé ultérieurement.

Stressor : dégradation ou vandalisme

Les bornes sont exposées :

aux accidents,
au vandalisme,
aux dégradations volontaires.

Le résidu naïf est une borne hors service, sans visibilité sur la cause. Pour améliorer ce résidu, on introduit :

des capteurs de diagnostic,
des caméras,
de la redondance matérielle.

Le résidu devient :

un système partiellement fonctionnel,
une capacité d’analyse a posteriori,
et une responsabilité traçable.

Stressor : occupation abusive

Un utilisateur branche son véhicule et le laisse immobilisé pendant des heures.

Le résidu naïf :

une borne inutilisable,
un actif bloqué,
aucun levier d’action.

Résidu amélioré (en s’appuyant sur des résidus précédents) :

identification du véhicule,
facturation différenciée dans le temps,
pénalisation progressive.

Le résidu devient économiquement favorable à l’opérateur.

Stressor imprévisible : « icing »

Un phénomène social émerge : des conducteurs de véhicules thermiques bloquent volontairement les bornes pour empêcher la recharge, par opposition idéologique.

Ce stressor :

n’aurait jamais figuré dans un registre de risques,
n’est pas technique,
n’est pas rationnel.

Pourtant, il survient. Mais grâce aux résidus accumulés :

identification des véhicules,
facturation à l’occupation,
preuves visuelles,
redondance du réseau,

le système absorbe ce stressor sans modification majeure.

Ce scénario, impossible à prédire, est couvert par des décisions architecturales prises pour des raisons entièrement différentes.

Ce que montre l’exemple

Cet exemple illustre plusieurs points essentiels :

Les stressors pertinents ne sont pas nécessairement plausibles.
Les résidus ont une portée bien plus large que le stressor qui les a générés.
Les événements sociaux et humains sont souvent les plus destructeurs.
Une architecture résiduelle n’empêche pas les crises, mais elle les rend exploitables.

Une posture architecturale différente

À ce stade, le rôle de l’architecte change profondément. Il ne cherche plus à prédire, à optimiser, ni à figer quoi que ce soit. Il cherche à provoquer des ruptures conceptuelles, à observer ce qui survit, à renforcer ces survivances et les rendre compatibles entre elles. L’architecture n’est plus une projection vers l’avenir, mais une préparation à l’effondrement.

Intégrer les résidus : couplages invisibles, contagion et validation empirique

Le moment critique de l’architecture

La construction progressive de résidus ne constitue pas, en soi, une architecture. Elle en est seulement la matière première. Si l’on se contente d’accumuler des composants, des mécanismes et des capacités destinées à améliorer la survie du système face à des stress successifs, on aboutit rapidement à une structure lourde, coûteuse et difficilement maîtrisable. L’enjeu réel de l’architecture commence précisément à l’instant où ces résidus doivent être réunis dans un tout cohérent.

C’est à ce moment que se révèle la difficulté la plus profonde du métier d’architecte logiciel.

Dans les pratiques courantes, cette difficulté est souvent masquée par l’application disciplinée de principes bien connus. Séparation des responsabilités, faible couplage, encapsulation et modularité produisent des architectures propres, rationnelles, bien découpées. Les composants paraissent indépendants, les dépendances explicites, les responsabilités clairement identifiées. Sur le papier, tout semble maîtrisé.

Pourtant, lorsque le système est confronté à un stress réel issu de son environnement, cette structure soigneusement élaborée se révèle fréquemment fragile.

Le couplage qui n’apparaît pas dans le code

Prenons un système composé de plusieurs composants que l’architecte a explicitement décidé de découpler. Ils n’échangent pas directement de données. Ils ne présentent aucune dépendance fonctionnelle apparente. Du point de vue du code, ils sont indépendants.

Un stress issu de l’environnement survient. Ce stress affecte simultanément ces composants.

Dans une lecture strictement technique, aucun lien nouveau n’apparaît. Mais du point de vue des sciences des réseaux, un lien existe bel et bien. Si un même événement externe entretient une relation avec deux éléments du système, alors ces éléments sont liés, indépendamment de toute intention de conception.

Ce lien n’est ni fonctionnel ni structurel au sens classique. Il est hyperliminal. Il naît précisément dans cet espace intermédiaire où le logiciel rencontre son environnement réel.

Ce type de couplage reste invisible tant que le stress ne s’est pas manifesté. Lorsqu’il apparaît, l’équipe découvre soudain que des composants supposés indépendants doivent évoluer ensemble, parfois sous la responsabilité d’équipes différentes, avec des contraintes organisationnelles distinctes. C’est à ce moment que l’architecture devient soudainement coûteuse à faire évoluer.

Pourquoi ces couplages sont systématiquement manqués

Les ingénieurs sont très efficaces pour raisonner sur les chaînes de traitement, les dépendances explicites et les flux fonctionnels. En revanche, ils sont structurellement mal armés pour percevoir les couplages induits par l’environnement, par l’usage réel du système, par l’infrastructure ou par l’organisation.

Or ce sont précisément ces couplages qui provoquent les ruptures les plus coûteuses. Ils expliquent pourquoi tant de projets échouent sur des aspects qualifiés a posteriori de « non fonctionnels », alors même que l’architecture semblait correcte.

Ce constat conduit à un changement de perspective. Il ne suffit plus de raisonner sur ce que fait le système lorsqu’il fonctionne normalement. Il faut comprendre comment il réagit lorsqu’il est soumis à des perturbations.

C’est dans ce contexte qu’émerge la notion d’analyse de contagion.

Le stress comme révélateur structurel

Lorsqu’un stress affecte simultanément plusieurs parties du système, il agit comme un agent de contagion. Il révèle que ces parties participent, qu’on le veuille ou non, à une même dynamique de survie ou d’échec.

Pour rendre cette dynamique visible, il est nécessaire d’adopter un outillage conceptuel issu des sciences des réseaux. Les diagrammes classiques atteignent rapidement leurs limites. Dès que l’on raisonne en termes de relations multiples et indirectes, la matrice devient l’outil central.

La matrice d’adjacence permet de représenter les relations structurelles entre fonctions, flux ou composants. Elle rend visibles les dépendances explicites et donne une première estimation du degré de couplage global du système. Une matrice peu dense correspond à une architecture relativement ordonnée. À mesure que la densité augmente, le système devient plus difficile à comprendre et à faire évoluer.

Mais cette matrice ne dit rien de la réaction du système à son environnement. Elle décrit ce qui est conçu, pas ce qui se produit.

Quand les exigences non fonctionnelles émergent

La matrice d’incidence introduit un changement décisif. Elle met en relation les stressors et les éléments du système. Elle ne décrit pas le fonctionnement nominal, mais les effets des perturbations.

Lorsqu’un même stress affecte de nombreuses parties du système, il devient évident que l’on est face à une contrainte transversale. Une exigence non fonctionnelle émerge alors, non pas comme une abstraction issue d’une checklist, mais comme une propriété révélée par le comportement du système sous contrainte.

De la même manière, certains composants apparaissent affectés par un grand nombre de stress différents. Ils deviennent des points de fragilité structurelle. D’autres stress, au contraire, se révèlent particulièrement contagieux, augmentant fortement le couplage global du système et signalant la nécessité d’un changement de structure.

Un phénomène encore plus révélateur apparaît lorsque deux éléments du système réagissent exactement de la même manière à l’ensemble des stress observés. Cela signifie qu’ils vivront et mourront ensemble. Les séparer est une illusion architecturale. À l’inverse, des éléments presque identiques, à une variation près, signalent un danger plus subtil : cette variation est précisément l’endroit où un stress futur provoquera une rupture.

Mesurer le progrès sans prédire l’avenir

Reste une objection majeure. Les stressors sont subjectifs. Ils dépendent du contexte, des personnes et de leur imagination. Comment démontrer que ce travail architectural produit autre chose qu’une architecture simplement différente ?

La réponse apportée par la théorie de la résidualité est empirique. On distingue une architecture naïve et une architecture résiduelle. Une partie des stressors est utilisée pour construire cette dernière. Les autres sont conservés comme jeu de test.

Ces stressors de test sont ensuite appliqués aux deux architectures. Pour chacun d’eux, on observe laquelle survit le mieux dans l’attracteur correspondant. Une mesure simple permet alors de calculer un indice compris entre -1 et 1, indiquant si l’architecture résiduelle est plus apte à survivre à des perturbations non anticipées.

Lorsque cet indice est positif, le travail architectural a produit un gain mesurable. Il ne repose plus uniquement sur l’intuition ou le récit, mais sur une amélioration objectivable de la robustesse du système.

De l’intuition à l’ingénierie

La théorie de la résidualité ne promet ni le contrôle ni la prédiction. Elle propose de rendre explicite ce qui était jusque-là implicite, de transformer une compétence tacite en méthode transmissible, et de déplacer l’architecture logicielle du registre de l’intuition vers celui de l’ingénierie.

Les systèmes logiciels resteront hyperliminaux. Ils continueront de vivre entre ordre et désordre. Mais l’architecte peut désormais choisir comment ils se brisent, et surtout ce qui restera quand ils se briseront.

Note sur le périmètre d’application de la théorie

En conclusion de son intervention, Barry O’Reilly insiste sur une limite d’application essentielle de la théorie de la résidualité. Celle-ci ne constitue pas une théorie générale de conception, et n’a pas vocation à être appliquée indistinctement à tout type de système.

La théorie de la résidualité est spécifiquement conçue pour les systèmes logiciels, et plus précisément pour des systèmes que l’auteur qualifie d’hyperliminaux : des systèmes situés à l’interface entre un artefact technique ordonné — le logiciel — et un environnement humain, organisationnel ou économique profondément complexe et imprévisible.

Son efficacité repose précisément sur l’existence de cette partie ordonnée, formellement maîtrisable, sur laquelle l’ingénierie logicielle peut agir. Dès que l’on tente d’appliquer directement cette approche à des systèmes purement humains — organisations, entreprises, structures sociales, politiques ou managériales — ce levier disparaît. Le nombre de nœuds devient trop élevé, les relations trop variables, et la base mathématique sur laquelle repose la méthode cesse d’être exploitable.

Barry O’Reilly met donc explicitement en garde contre toute tentative de détourner la théorie de la résidualité vers le design d’organisations, le management ou le conseil en transformation. Un tel usage, outre le fait d’être inadapté, risquerait de discréditer la théorie en l’appliquant en dehors de son domaine de validité.