Implémenter les user stories les unes après les autres sans explorer profondément le domaine optimise la vitesse à court terme, mais crée une fragilité structurelle qui finit par faire chuter brutalement le delivery.
Introduction
Aujourd’hui, l’agilité s’est imposée comme le cadre de développement par défaut pour la majorité des logiciels. Et pour de bonnes raisons : dans des environnements complexes, changeants, et largement imprévisibles, les approches strictement séquentielles ont montré leurs limites.
C’est précisément pour cela que je prends l’exemple de l’agile dans cet article. Non pas parce qu’il serait inefficace, mais au contraire parce qu’il est souvent le seul cadre dans lequel il est encore possible de bien faire — à condition de ne pas en réduire l’usage à un simple enchaînement de user stories.
Dans de nombreuses équipes, pour des raisons structurelles, organisationnelles ou culturelles, le développement se résume à implémenter les user stories les unes après les autres, en se concentrant exclusivement sur le besoin immédiat et son “happy path”. Toute tentative de prise de recul est alors repoussée : « on verra plus tard », « ça peut changer », « ce n’est pas prioritaire, concentre-toi sur le delivery ».
Cette approche est souvent rationnelle localement. Elle permet de livrer vite, de montrer de la valeur, et de maintenir un flux constant. Et c’est précisément pour cela qu’elle est séduisante. Le problème n’est pas qu’elle ne fonctionne pas — le problème est qu’elle fonctionne très bien… jusqu’à ce qu’elle cesse brutalement de fonctionner.
L’objectif de cet article n’est pas de remettre en cause l’agilité, ni de défendre un retour à des modèles idéalisés et non itératifs. Il est d’expliquer, de manière systémique, pourquoi une application strictement opportuniste de l’agilité tend à produire des systèmes localement optimisés mais structurellement fragiles, et pourquoi cette fragilité se traduit presque toujours, à moyen terme, par une chute drastique du delivery.
La théorie de la résidualité
Les systèmes face au changement
Un logiciel n’est pas un objet figé, mais un système soumis en permanence au changement : nouvelles fonctionnalités, évolutions métier, contraintes externes, variations de charge. Le changement n’est pas un incident du développement logiciel, il en est la norme.
Pourtant, la qualité d’un système est souvent évaluée à un instant donné : ce qu’il fait, comment il le fait, s’il respecte certaines règles ou bonnes pratiques. Ces critères sont utiles, mais insuffisants. Ils disent peu de la manière dont le système réagira aux changements à venir.
Or, ce qui distingue durablement un système robuste d’un système fragile n’est pas son état actuel, mais le coût qu’il supporte à chaque évolution. Deux systèmes peuvent produire les mêmes fonctionnalités aujourd’hui, tout en ayant des comportements radicalement différents face au changement.
La question centrale n’est donc pas « est-ce que le système fonctionne ? », mais « combien lui coûte chaque changement ? ». Et surtout : comment ce coût évolue dans le temps.
C’est précisément ce type de dynamique que la théorie de la résidualité cherche à expliquer : non pas pourquoi un système fonctionne à un instant donné, mais pourquoi certains continuent à fonctionner malgré les changements, là où d’autres finissent par se dégrader brutalement.
Stressors et propagation du changement
Dans la théorie de la résidualité, un système n’évolue jamais de manière abstraite. Il évolue toujours en réponse à des variations concrètes : une nouvelle fonctionnalité, un changement de règle métier, une contrainte externe, une montée en charge, une réorganisation. Ces variations sont appelées des stressors.
Un stressor n’est pas défini par sa nature — il peut être fonctionnel, technique ou organisationnel — mais par son effet : il force le système à changer.
Un changement peut rester localisé, ou au contraire se propager largement. Dans certains systèmes, une évolution ne touche qu’un nombre limité d’éléments. Dans d’autres, la moindre modification entraîne une cascade d’ajustements.
Cette propagation du changement constitue un indicateur central de la santé structurelle d’un système. Plus un changement affecte d’éléments, plus son coût augmente — en effort, en coordination et en risque.
Deux systèmes peuvent répondre au même stressor tout en ayant des comportements radicalement différents face au changement. La différence ne tient pas au stressor lui-même, mais à la structure du système et à la manière dont ses éléments sont liés.
La résidualité s’intéresse précisément à cette dynamique dans le temps : comment, sous l’effet de stressors successifs, la propagation du changement tend à s’amplifier ou à se contenir, et comment cette évolution conditionne la capacité du système à continuer à évoluer.
Résidus et fragilité structurelle
Lorsqu’un système évolue sous l’effet de stressors successifs, il ne revient jamais à son état initial. Chaque adaptation laisse une trace dans sa structure : choix de conception, compromis, dépendances introduites. Cet ensemble de traces constitue ce que la théorie de la résidualité appelle le résidu.
Le résidu n’est ni un défaut ni une qualité en soi. Il est la conséquence inévitable du fait qu’un système a survécu aux changements qu’il a rencontrés. Ce qui n’a pas résisté aux stress subis disparaît ; ce qui a permis au système de continuer à fonctionner demeure, parfois au prix de nouveaux compromis.
Selon la nature des stressors rencontrés et la manière dont le système y a répondu, les résidus peuvent soit renforcer la structure, en absorbant les changements et en limitant leur propagation, soit au contraire la fragiliser, en augmentant les dépendances implicites et en rendant chaque évolution plus coûteuse que la précédente.
Cette fragilité structurelle est rarement visible immédiatement. Un système peut continuer à fonctionner, et même à livrer, tout en accumulant des résidus défavorables. Ce n’est que lorsque les stressors se diversifient ou s’intensifient que la dégradation devient manifeste : la propagation du changement s’amplifie, les coûts explosent, et la capacité d’évolution s’effondre.
Du point de vue de la résidualité, la qualité d’un système ne se mesure donc pas à sa propreté apparente ou à sa conformité à un idéal théorique, mais à la nature des résidus qu’il accumule et à sa capacité à continuer à évoluer sans que le coût du changement ne devienne prohibitif.
Repositionnement
La théorie de la résidualité est souvent présentée comme une théorie de l’architecture logicielle. Et c’est légitime : elle permet d’analyser la manière dont des systèmes complexes, composés de multiples éléments en interaction, réagissent au changement dans le temps. Mais réduire la résidualité à un seul niveau d’analyse serait une erreur.
La résidualité est fondamentalement multi-échelle. Elle peut s’appliquer :
- au niveau global d’un système ou d’un paysage applicatif,
- au niveau intermédiaire de ses composants et de leurs interactions,
- et, dans certaines limites, au niveau plus fin du design et du code.
À chaque niveau, elle permet d’observer comment les changements se propagent, quels résidus sont produits, et quelles formes de fragilité ou de robustesse émergent. Mais cela ne signifie pas qu’elle doive être appliquée partout de la même manière, ni avec la même utilité. Comme toute grille de lecture, elle n’est pertinente que si le niveau d’analyse choisi correspond au problème que l’on cherche à comprendre.
Dans cet article, nous faisons donc un choix délibéré : nous plaçons l’analyse au niveau du modèle logiciel.
Par modèle logiciel, on entend ici la partie du système où se concentrent les concepts centraux, les règles métier, les invariants et les décisions structurantes — indépendamment des choix d’architecture technique, des frameworks ou des modes d’exposition. C’est le cœur logique du système, celui qui encode la compréhension (ou l’incompréhension) du domaine.
Ce choix n’est pas anodin. C’est à ce niveau que se cristallisent la plupart des effets à moyen et long terme :
- la manière dont les règles sont exprimées ou dispersées,
- la facilité à faire évoluer une décision sans en casser d’autres,
- la capacité à absorber des variations du métier sans propagation excessive du changement.
C’est également à ce niveau que se joue une grande partie de la tension entre delivery rapide et capacité d’évolution.
Appliquée à ce niveau, la résidualité permet de poser une question simple mais puissante : quels types de stressors ce modèle est-il réellement exposé à, et quels résidus cette exposition produit-elle ?
Ces stressors peuvent être de natures très diverses. Certains sont volontairement extrêmes ou improbables : changements radicaux de contexte, hypothèses absurdes, scénarios “hors trajectoire”. Leur intérêt n’est pas leur réalisme, mais leur capacité à forcer l’exploration au-delà de ce que le système a déjà rencontré.
D’autres sont plus proches de la réalité quotidienne : passage d’un contexte B2B à un contexte B2C, internationalisation, nouvelles contraintes réglementaires, changement d’échelle, évolution des responsabilités métier. Tous ces stressors interrogent directement la structure du modèle et la manière dont ses concepts sont liés.
Enfin, il y a les stressors plus proche des développeurs : les user stories, les évolutions fonctionnelles, les ajustements incrémentaux. Eux aussi mettent le modèle sous contrainte.
En repositionnant ainsi la résidualité au niveau du modèle logiciel, nous disposons maintenant d’un cadre clair pour examiner la thèse de départ de cet article : enchaîner des user stories sans chercher à comprendre profondément le domaine est une source mécanique de fragilité structurelle.
Quand le développement se réduit à une succession de user stories
Dans la pratique quotidienne du développement logiciel, on n’utilise quasiment jamais une approche qui expose volontairement le système à une grande variété de changements. Le plus souvent, le modèle est uniquement confronté à ce que le backlog lui propose : une suite de user stories, formulées dans un cadre connu, implémentées une à une. Les autres formes de stress — changements de contexte, ruptures de règles, évolutions radicales de l’usage, contraintes inattendues — sont rarement envisagées, même à titre exploratoire. Du point de vue de la résidualité, cette faible diversité de stressors pose un problème structurel : un système qui n’est exposé qu’à un spectre très étroit de changements ne peut produire que des résidus adaptés à ce spectre.
Cette situation est encore accentuée lorsque les développeurs sont peu ou pas en contact avec le métier. Leur vision du système se limite alors à l’enchaînement des user stories. Lorsqu’ils cherchent à comprendre comment le domaine pourrait évoluer — non pas pour implémenter immédiatement, mais pour orienter leur conception — les réponses sont souvent les mêmes : « on verra plus tard », « ça peut changer », « ne sur-concevons pas », « concentrons-nous sur le besoin actuel ». Ces réponses ferment explicitement la porte à toute exploration du futur possible du domaine. Elles réduisent drastiquement l’exposition du modèle au changement, et donc la variété des stressors auxquels il est confronté.
Le problème n’est pourtant pas que les user stories seraient de “mauvais” stressors. Elles sont parfaitement légitimes. Elles font partie intégrante de la vie d’un produit et d’une équipe agile. Elles obligent le modèle à évoluer, à s’enrichir, à intégrer de nouvelles règles ou de nouveaux comportements. Mais elles possèdent une caractéristique structurelle forte : elles sont corrélées entre elles. Elles prolongent presque toujours les concepts existants, les règles déjà en place et les hypothèses implicites du modèle. Elles explorent rarement ce qui se trouve en dehors de la trajectoire actuelle du système. Autrement dit, elles stressent le modèle dans la continuité de son passé, pas dans la diversité de ses futurs possibles. Dans ce contexte, le modèle apprend — parfois très efficacement — mais il apprend toujours la même chose.
Du point de vue de la résidualité, cela conduit à une forme de sélection très particulière. À chaque user story, ce qui permet au modèle de répondre rapidement est conservé. Ce qui complique l’implémentation est contourné, repoussé ou rigidifié. Des résidus se forment, adaptés à ce type précis de stress. Progressivement, le modèle devient très efficace localement : le delivery est fluide, les changements sont rapides, la vélocité augmente. Mais cette efficacité est trompeuse. Elle repose sur une exposition extrêmement étroite aux stressors. Le modèle n’est pas préparé à absorber des variations de contexte, des ruptures de règles métier, des changements de responsabilité ou des combinaisons inédites de comportements. Il est résiduel, certes — mais résiduel d’un monde minuscule.
Conclusion
Ce que la résidualité nous apprend sur nos façons de développer.
Dans le cadre des logiciels complexes — c’est-à-dire des systèmes soumis à des évolutions fréquentes, imprévisibles et fortement dépendantes de leur contexte — toutes les approches de développement ne se valent pas face au changement.
Les approches non itératives, fondées sur une conception largement figée en amont, reposent sur une hypothèse forte : celle de pouvoir anticiper correctement l’essentiel des évolutions futures du système. Dans des contextes complexes, cette hypothèse est rarement vérifiée. Ces approches exposent peu le système au changement réel, et souvent trop tard. Du point de vue de la résidualité, elles produisent des structures faiblement adaptatives, dont la fragilité apparaît dès que les hypothèses initiales sont mises en défaut.
Les approches itératives offrent, en comparaison, un potentiel bien supérieur. Lorsqu’elles exposent le système à une diversité suffisante de changements — fonctionnels, métier, contextuels ou organisationnels — elles permettent au modèle de se transformer progressivement, d’accumuler des résidus plus favorables, et de maintenir une capacité d’évolution dans le temps. Dans ce cas, l’itération joue pleinement son rôle : non seulement livrer, mais apprendre face à l’incertitude.
Cependant, toutes les formes d’itération ne produisent pas les mêmes effets. Une itération réduite à l’enchaînement de user stories, sans compréhension approfondie du domaine par les développeurs, sans exploration des évolutions possibles du métier, et sans remise en question des invariants implicites, expose le modèle à un spectre de stress extrêmement étroit. La résidualité qui en résulte est alors adaptée à un monde local et stable, mais peu préparée à la diversité des changements à venir. La capacité d’évolution se dégrade progressivement, jusqu’à ce que la fragilité structurelle devienne manifeste.
Il n’est pourtant pas nécessaire d’adopter l’intégralité de la théorie de la résidualité pour en tirer des bénéfices concrets. Sans modèles formels ni outillage spécifique, un premier pas consiste simplement à élargir la vision du changement à laquelle le modèle est exposé. Donner aux développeurs une compréhension plus large du domaine, leur permettre de questionner les invariants, d’envisager des évolutions possibles — même incertaines ou improbables — suffit déjà à modifier profondément la nature des résidus produits.
L’objectif n’est pas de tout anticiper, ni de concevoir un système prétendument parfait. Il s’agit seulement de ne pas enfermer prématurément le modèle dans une vision trop étroite de son futur.
