Un vétéran de 30 ans explique pourquoi l'IA ne peut pas remplacer les architectes logiciels

Pourquoi l’architecture pratique reste gagnante à l’ère de l’IA

Dennis Doma est un vétéran de l’ingénierie logicielle avec 30 ans d’expérience, Microsoft MVP, et le créateur de Fluent Assertions — l’une des bibliothèques de tests open source les plus populaires de l’écosystème .NET. En tant qu’architecte logiciel chez Aviva Solutions, il a passé des décennies à combattre la complexité qui tue les logiciels d’entreprise. Dans cette conversation avec Beyond Coding, il explique comment les outils d’IA transforment son workflow — et où ils montrent leurs limites.

Sur les architectes qui arrêtent de coder : “If you stop coding, if you actually stop building production systems, you lose that experience. If I had stopped coding for the last 3 years, I would have probably missed the whole AI scene.” (Si vous arrêtez de coder, si vous cessez réellement de construire des systèmes en production, vous perdez cette expérience. Si j’avais arrêté de coder ces 3 dernières années, j’aurais probablement raté toute la révolution IA.) Doma soutient que les architectes logiciels qui se réfugient dans les schémas de haut niveau perdent la capacité de juger si les solutions fonctionnent réellement. La boucle de rétroaction pratique — construire, livrer, corriger des bugs — est irremplaçable.

Sur la propriété du code généré par l’IA : “I treat all AI-generated code as mine.” (Je traite tout le code généré par l’IA comme le mien.) Quand GitHub Copilot a construit la majeure partie de sa nouvelle bibliothèque de mocking open source à partir d’un seul ticket, Doma était impressionné — mais a immédiatement pris les rênes. Il relit les tests générés par l’IA ligne par ligne, refactorise le code qui ne répond pas à ses exigences, et met à jour itérativement les fichiers d’instructions pour que les générations futures s’améliorent. Le code n’est pas “le code de l’IA” — c’est sa responsabilité.

Sur la complexité accidentelle : Des équipes copient aveuglément des patterns architecturaux — architecture en oignon, clean architecture — sans comprendre pourquoi ils existent. Des développeurs avec 10 à 15 ans d’expérience deviennent “trop zélés” dans leur attachement aux principes SOLID, les brandissant comme des boucliers contre le pragmatisme. “Yeah, but you don’t need this abstraction. Yeah, but it’s ready for the future. You don’t need this abstraction. That’s a smell.” (Oui, mais vous n’avez pas besoin de cette abstraction. Oui, mais c’est prêt pour l’avenir. Vous n’avez pas besoin de cette abstraction. C’est un signal d’alerte.)

Sur les développeurs juniors et l’IA : Deux profils émergent — ceux qui évitent l’IA pour préserver leurs compétences d’apprentissage, et ceux qui l’utilisent partout sans comprendre ce qu’elle produit. Doma a rencontré un développeur dont la pull request fonctionnait (les tests passaient) mais qui ne pouvait pas expliquer ce que faisait le code. Sa réponse : “I don’t care if you don’t practice TDD properly, but make sure the code is designed the way we want it and we can maintain it.” (Peu m’importe si vous ne pratiquez pas correctement le TDD, mais assurez-vous que le code est conçu comme nous le souhaitons et que nous pouvons le maintenir.)

Sur la viabilité de l’open source : L’équipe Tailwind a licencié 75 % de ses effectifs parce que l’IA peut reproduire leurs composants premium. La réponse de Doma : les gens sous-estiment chroniquement la complexité qui se cache derrière les bibliothèques matures. “J’ai passé 15 ans à perfectionner Fluent Assertions. Quelqu’un dit ‘je peux construire ça en quelques jours.’ Bien sûr.” Le code open source peut devenir votre code à maintenir — planifiez en conséquence.

5 leçons d’un architecte logiciel sur le développement assisté par IA

• Les tests sont votre filet de sécurité — Que le code soit écrit par un humain ou généré par l’IA, des tests robustes sont le validateur ultime. “Si vous traitez le logiciel comme une boîte noire et que votre filet de sécurité ce sont vos tests, vous devez y accorder une attention toute particulière.”
• La documentation se capitalise avec l’IA — Les ADR, les messages de commit et les registres de décisions prennent une valeur considérable quand les outils d’IA peuvent les parcourir. Les entreprises qui investissent dans un contexte riche auront “une longueur d’avance considérable.”
• Laissez les équipes choisir leurs propres outils IA — N’imposez pas un outil unique. “Laissez les gens utiliser l’outil IA qu’ils préfèrent, car ça change constamment.” Suivez l’utilisation, étendez les licences, mais ne bridez pas l’expérimentation.
• Le contexte est comme du lait — Doma a appris à ses dépens les effets de la compression de contexte : son IA a fusionné et poussé du code expérimental sur la branche principale. Les branches de fonctionnalités et les commits fréquents sont des garde-fous essentiels.
• L’open source en vaut toujours la peine — “Vous donnez, mais vous recevez tellement en retour. Connaissances, expérience, nouveaux outils, nouvelles perspectives, visibilité.” Le retour sur investissement ne se résume pas au code — c’est la boucle de rétroaction communautaire.

Ce que cela signifie pour les équipes logicielles propulsées par l’IA

La perspective de Doma tranche avec les discours enthousiastes : les outils de codage IA sont véritablement transformateurs pour la vitesse d’exécution, mais ils ne remplacent pas le jugement architectural forgé par des décennies d’expérience pratique. Les développeurs qui s’épanouiront seront ceux qui utilisent l’IA comme un outil puissant tout en conservant leur esprit critique — en comprenant pourquoi les patterns existent, pas seulement en les appliquant. Pour les organisations, le message est clair : investissez dans la documentation, la qualité des tests et le mentorat architectural. Ce sont les actifs qui se valorisent quand l’IA s’occupe de la frappe.