La Duck Conf 2026 - Architect Paradox : Pourquoi personne ne veut parler aux architectes

Avec humour et un “blue style” * cette année, Lana Lesik, consultante chez OCTO Technology nous parle des architectes en chair et en os; et non pas des patterns d’architecture.

Pour introduire son propos, Lana cite Kent Beck qui en 1992, a expliqué que le titre d’architecte avait été utilisé pour justifier les niveaux de salaires élevés des développeurs.

C’est à partir de cette citation que Lana a organisé sa présentation et préfère avertir son auditoire avec un premier disclaimer :

Disclaimer #1 : de quoi parle-t-on ?

1. Il s’agit d’une analyse à partir de sa propre histoire et de son expérience
2. Lana partage son observation des architectes en tant que personne et non pas de patterns techniques
3. Elle avertit que ce n’est pas une généralisation : cela ne concerne pas tous les architectes

Lana présente alors ses deux casquettes : après avoir été psychologue dans les hôpitaux, elle est devenue développeuse Mobile front et back pour finalement (ou temporairement) prendre la casquette d’architecte.

Elle aime bien voir les patterns et les systèmes. Elle a justement appris l’approche systémique en tant que psychologue, qui lui permet de voir les patterns à la fois dans la communication et dans les comportements ; ce qu’elle peut à présent appliquer au monde des architectes.

Acte I : Il se passe quelque chose d’étrange

Lana Lesik imaginait qu’en tant qu’architecte, elle allait être dans les décisions quand ses collègues à l’époque lui expliquent qu’elle ne codera plus et passera son temps en réunion.

Elle s’est demandée pourquoi sa vision s’opposait à celle de sescollègues, ou d’autres développeurs.

Elle nous présente pourquoi l’architecture et les architectes ont une mauvaise réputation :

• Ils élaborent une vision de l’architecture à 7-8 ans
• Les architectes prennent les décisions - Thinkers ; les autres font - Doers
• Leur langage est incompréhensible (schéma directeur pour le flux de valeur)
• On ne peut pas apprendre l’architecture: cela vient avec l’expérience
• Etc.

S’il existe autant de stéréotypes, pourquoi y a-t-il des architectes en entreprise?

Acte II : The Upside Down

Comment les architectes vivent cette mauvaise réputation ?

Quand on veut devenir architecte, il y a plusieurs types comme décrit ci-dessous dans l’image:

Un architecte solution est-il le même que l’architecte applicatif ? Cela dépend du contexte de l’entreprise.

Qui plus est, il faut créer son propre poste. Gregor Hophe utilise la métaphore de l’ascenseur par lequel l’architecte doit être capable de parler à tous les métiers de l’entreprise et maîtriser un périmètre énorme.

Il existe différents types d’architecte :

• L’architecte qui code: il va dans le repository pour montrer comment faire
• L’architecte tour d’ivoire : il développe le schéma UML et on ne le revoit plus
• L’architecte as-a-service : si une architecture a marché une fois, cela doit marcher dans tous les contextes.

Le métier de l’architecte change avec l’arrivée de l’intelligence artificielle. Lana en profite pour montrer une frise chronologique de l’évolution des métiers de l’architecte.

Cette frise permet d’observer que le métier d’architecte change environ tous les dix ans. Cela implique pour les architectes d’avoir une grande capacité d’adaptation.

Dans l’ère de l’IA, la fréquence des décisions d’un architecte augmente énormément : s’il prenait une décision une fois par jour, à présent cela peut être une à plusieurs fois par heure.

Cela accélère les biais cognitifs dans la prise de décision car comme toute personne, l’architecte est avant tout un humain. Il existe 3 types de biais:

• Le biais d’ancrage se traduit par l’influence que peut avoir une première information reçue pouvant influencer les décisions prises ultérieurement
• Le biais de confirmation se traduit par sélectionner les informations qui renforcent l’hypothèse émise
• Le biais de framing s’observe dans le fait que la question de cadrage peut influencer la réponse apportée.

Prendre des décisions étant le cœur de métier des architectes, cette accélération rend plus compliqué le processus de décision.

L’IA a également un impact sur l’organisation:

• Un tech lead peut travailler avec plusieurs agents
• L’architecture peut devenir évolutive : anticiper le fonctionnement effectif d’applications de l’organisation quand survient tel ou tel événement.

Ces évolutions posent la question de la place de l’architecte dans l’entreprise:

• Chez les OPS - Opération, alors qu’il y a le SRE - Site Reliability Engineery
• Chez les Dev - alors qu’il y a le Tech lead?
• etc.

Le risque dans ces évolutions se sont les silos qui contribuent eux-même à renforcer les stéréotypes puisque personne ne se parle.

Disclaimer #2 L’architecture existe de toute façon

Même si les équipes sont autonomes, il est important de prendre en compte l’architecture pour éviter des coûts financiers à terme dû à des mauvais choix.

Partant de son expérience en start-up, Lana explique qu’au démarrage dans ces structures, il n’y a pas d’architecte faute d’argent. Or au moment du passage à l’échelle, les choix pris au démarrage montrent que des réflexions autour de comment réaliser ce passage à l’échelle, comment intégrer de nouveaux marchés n’ont pas été pensés / anticipés.

Aussi, Lana partage que la start-up en question a été obligée de recoder toute l’application ce qui a eu pour conséquence, un coût financier important.

ACTE III : Opening the Gates

Comment faire interagir ensemble architectes et reste de l’organisation?

Pour ce faire, il est nécessaire d’analyser les 5 frictions prioritaires à lever:

• Pour lutter contre le rôle flou, l’architecte passe des contrats explicites avec toutes les composantes de l’entreprise, des Métiers aux OPS, afin de recueillir leurs attentes et de clarifier à la fois celles auxquelles ils pourront répondre de même que les moyens de communication.

Cette étape est une évidence, régulièrement oubliée. Qui plus est, il ne faut pas hésiter à clarifier les rôles et responsabilités même dans des équipes matures.

• Pour casser le mur entre les architectes et les équipes, il est important d’encourager le rôle des Walking Architects : encourager les architectes à être présents dans les différentes instances pour comprendre les besoins dans les équipes.

Le travail de l’architecte repose sur 20% de schémas et 80% de communication : un schéma UML expliqué par un architecte permet aux développeurs de comprendre les contraintes et pourquoi telles décisions doivent être prises. Cela nécessite du temps.

• “On ne peut pas apprendre l’architecture” : scientifiquement, le fait de mobiliser l’inquiry-based learning (apprentissage par les problématiques) permet d’appréhender le rôle.

Pour un architecte, cela se traduit par sa participation à des brainstormings et autres katas lors desquels il doit présenter les solutions, argumenter et assumer les conséquences de ses choix.

• Pour calmer le bruit conceptuel tels que schéma directeur, chaîne de valeur, ROI (Return of Investment), etc., vocabulaire plus ou moins technique que peu de personnes maîtrise et vont être capables de questionner le sens, le Domain Driven Design (Lana encourage à regarder le talk de Bruno Boucard à ce sujet) soutient la création d’un langage commun, une évidence mais peu mise en place.

• L’architecture ne reflète pas la réalité. Le repository de l’architecte n’est jamais consulté sur Confluence ou autre wiki. En mobilisant les pratiques du Craftsmanship, les développeurs peuvent travailler aux côtés des architectes, intégrer les librairies d’architecture dans les tests. Le code doit raconter l’histoire et être la source de vérité: néanmoins, cela ne peut pas refléter les dépendances avec d’autres applications, avec les infrastructures etc. L’architecte doit ainsi effectuer un monitoring pour observer la cohérence entre le code et l’architecture.

En guise de conclusion, Lana a construit un Bingo de l’architecture pour résumer ses propos tout en montrant comment mettre en place des quick wins (cercles jaunes dans le tableau ci-après) :

Partant de ce bingo, Lana a une forte préférence pour le Walking Architecte.

Epilogue

L’architecte peut donner envie de lui parler quand :

• Il doit endosser le rôle de facilitateur
• Il doit influencer par la confiance plutôt que par le contrôle.L’architecte doit être en capacité de déléguer certaines décisions aux développeurs
• Il doit créer une coopération au travers du vocabulaire

La réciproque doit également exister et l’équipe doit collaborer:

• L’architecture est nécessaire ; charge à chacun de s’y intéresser
• Il faut faire vivre l’architecture dans le quotidien des équipes et pas seulement dans les schémas UML
• L’équipe doit s’emparer du langage commun quotidiennement.

L’objectif étant, comme une dernière évidence, de travailler ensemble comme une seule et même équipe.

* L’année dernière, Lana avait adpoté un style rose. Vivement l’année prochaine !

** Le livre de Gregor Hophe Platform Strategy a été traduit en français par les équipes d’OCTO Technology: Merci à Hana Amiri, Julien Tellier, Medhi Houacine