Dans nos métiers, la dette technique est sans doute la chose la plus frustrante, éprouvante et coriace contre laquelle nous devons lutter. Bien sûr, il existe des bonnes pratiques : refactoriser, viser la simplicité avec KISS, éviter de trop anticiper avec YAGNI afin de limiter cette dette au maximum. Et pourtant, on n’y vient jamais vraiment à bout. Pire encore, elle continue de s’accumuler même lorsque nous les appliquons, comme une fatalité.

Et si ces mêmes bonnes pratiques ne faisaient parfois qu’empirer le problème au lieu de le résoudre ? La dette technique peut n’être que la partie visible de quelque chose de plus profond : la dette de design accidentelle. Un problème bien plus complexe, donnant lieu à des logiciels spaghettis et à des microservices en « monolithe distribué », dont nous sommes souvent à l’origine sans même nous en rendre compte.

Dans cette conférence, nous explorerons les mécanismes de la dette de design et ses impacts, conséquents sur notre architecture, nos processus, notre organisation, et même notre business. À travers des exemples concrets, nous verrons comment la détecter, analyser sa profondeur et agir avant qu’elle ne s’ancre durablement.

Nous souhaitons aborder la notion de dette de design car elle est peut connue et comprise dans nos métiers. Beaucoup de personnes se retrouvent aujourd’hui enlisées dans la lutte contre la dette technique, car elles ne traitent pas du véritable problème, faute de grille de lecture sur la dette de design (tensions de modèle). C’est un sujet que nous avions introduit lors de Devoxx France 2024 avec la conférence « Model Mitosis : ne plus se tromper entre les microservices et le monolithe », notée 4,79.

Pour Devoxx France, nous proposons une version vulgarisée de notre dernière conférence “Model Tensions Heuristics: preventing accidental design debt”, présentée à NewCrafts 2025 ainsi qu’à DDD Europe 2025. Les slides et l’enregistrement de la version originale ont été fournis.

Plan de la conférence

1. La dette de design accidentelle

La dette de design accidentelle naît de l’accumulation de choix apparemment anodins mais qui, progressivement, introduisent du couplage, réduisent la cohésion, limitent la flexibilité et altèrent la justesse des modèles métier.
Lien entre cette dette et la façon dont nous construisons nos modèles métier, et mise en lumière de la manière dont certaines bonnes pratiques peuvent aggraver le problème (DRY, KISS, YAGNI), car elles ne traitent pas du bon problème.
Explication de la manière dont cette dette conduit à la création de véritables monolithes spaghettis, sous l’effet de l’entropie du design, c’est-à-dire la tendance d’un design à se désorganiser et à dissiper toujours plus notre énergie lors que l’on procède à des changements
Mise en lumière du modèle dit “Spork”, consistant à vouloir résoudre plusieurs problèmes distincts avec une seule et même solution.
2. Les tensions de modèle, l’origine de la dette de design

Présentation de la notion de tension de modèle : un “smell” qui indique que l’on force un changement à entrer dans un design qui ne lui correspond pas.
Analyse des raisons pour lesquelles ces tensions apparaissent et de la manière dont, en se cristallisant au fil du temps, elles deviennent des contraintes structurantes qui renforcent l’entropie du design.
Mise en perspective de ces tensions non seulement comme un problème, mais aussi comme un signal précieux permettant d’anticiper et de prévenir l’apparition d’une dette de design accidentelle.
3. Illustration pratique de ces tensions

Démonstration de ces phénomènes à travers plusieurs cas concrets :

Dans la construction d’un modèle métier, notamment via un atelier d’EventStorming
Dans la conception et la structure d’une API REST
Dans du code métier Java
Pour chaque cas, présentation de pistes de résolution permettant d’identifier, de corriger ou d’éviter ces tensions.
4. Les effets pervers et insoupçonné des services trop affectés par la dette de design

Illustration du mécanisme suivant : un service rigide et complexe conduit à la création d’un nouveau microservice pour contourner l’inertie d’un service existant, mais un couplage fonctionnel s’installe rapidement, forçant les deux services à être livrés simultanément.
Démonstration de la façon dont ces services finissent par former un monolithe distribué, faute d’avoir résolu le problème à la racine.
Mise en lumière des réponses compensatoires adoptées au niveau des processus et des organisations, comme l’usage de feature toggles ou l’apparition de rôles palliatifs afin de (sur-)synchroniser le travail des équipes pour éviter la fragilité du SI.
Analyse des dérives organisationnelles engendrées par des services fortement affectés par la dette de design accidentelle.
Enfin, mise en évidence du fait que ces tensions au niveau organisationnel ne sont qu’une autre expression des tensions initiales présentes dans le modèle,
Impacte de la loi de Conway.
5. Rétrospective et pistes de sortie

Présentation de la manière dont on a construit un faisceau de preuves en observant l’ensemble des composantes de l’entreprise afin d’identifier et d’évaluer la profondeur de la dette de design.
Ouverture sur des leviers concrets pour agir, enrayer cette dynamique et prévenir sa l’appartion de la dette de design.

Slides Link
https://slides.com/julientopcu/you-thought-technical-debt-was-bad-meet-design-debt
Video URL
https://www.youtube.com/watch?v=EZTl9FH5AFQ