Introduction : pourquoi ce livre change la donne
Fin 2024, l'ouvrage d'Andrew Harmel-Law, « Facilitating Software Architecture », paraissait chez O'Reilly. Il y défend une thèse simple mais dérangeante pour beaucoup d'organisations : la prise de décision architecturale peut, et doit, être décentralisée, pour responsabiliser les développeurs et les autres praticiens, pas seulement les architectes logiciels attitrés.
Deux ans après sa parution, le livre a largement dépassé le cercle des architectes d'entreprise pour irriguer les pratiques de plateforme interne, les guildes techniques et les revues d'architecture des organisations qui adoptent le modèle des équipes alignées par flux. Pour comprendre pourquoi cette approche résonne autant aujourd'hui, nous avons posé plusieurs questions à Andrew Harmel-Law sur les défis actuels de l'architecture logicielle, la manière dont son modèle se déploie concrètement, et les risques qu'il implique.
De l'architecte en tour d'ivoire à l'architecture comme pratique partagée
Olivier V. : Pourquoi les rôles d'architecte et de développeur ont-ils généralement été maintenus séparés ? Comment en est-on arrivé là ?
Andrew Harmel-Law : Il semble que ce soit simplement le fruit de l'évolution. Très tôt, c'est-à-dire à l'époque où j'ai commencé à écrire du code, l'architecture était perçue comme une activité plutôt que comme un titre de poste. La séparation des rôles entre différentes personnes a probablement résulté de l'accélération très rapide de la vitesse de développement et de l'augmentation du nombre de personnes travaillant sur les systèmes. Des problèmes ont sans doute aussi commencé à apparaître, créant le besoin d'une personne explicitement responsable et comptable des décisions architecturales.
Cette répartition des rôles s'est rapidement ancrée dans la culture du secteur, au point que les archétypes de l'architecte « en tour d'ivoire » et de l'architecte « mains sur le clavier » sont devenus des figures que chacun, dans le monde du logiciel, reconnaît instantanément.
OV : N'y a-t-il pas toujours eu une collaboration entre ces disciplines ? Qu'est-ce que vous défendez de différent par rapport à avant ?
AHL : Il devrait toujours y en avoir une, et dans les meilleures équipes, l'architecture est restée davantage un rôle que différentes personnes endossaient selon les besoins du moment. Quand c'est le cas, on observe généralement qu'il n'y a personne portant officiellement le titre d'« architecte » à proximité immédiate du code, même si d'autres types d'architectes peuvent encore être présents ailleurs dans l'organisation : c'est un terme très surchargé dans notre industrie, malgré son inadéquation relative avec la réalité du travail quotidien.
Cinq révolutions qui ont rendu l'architecture centralisée obsolète
OV : Pourquoi maintenant ? Qu'est-ce qui a changé dans notre façon de construire les logiciels ?
AHL : Dans le livre, je pointe cinq « révolutions » qui ont transformé notre capacité à faire passer une idée de la tête d'une personne jusqu'au code compilé réellement utilisé en production.
Agile, cloud et DevOps : le rythme de livraison explose
La première révolution a été le manifeste Agile, qui a éliminé une grande partie de la planification inutile. La deuxième a été l'informatique en nuage, qui a rendu les environnements d'exécution disponibles virtuellement en un clic, provisionner une infrastructure complète ne prend plus des semaines mais des minutes, via l'infrastructure as code. La troisième révolution a été DevOps, et en particulier le déploiement continu, qui a drastiquement réduit les cycles de livraison logicielle : des organisations qui déployaient en production tous les trimestres déploient aujourd'hui plusieurs fois par jour. Cela a permis de livrer bien plus qu'auparavant, et de le faire bien plus vite.
Pensée produit et équipes alignées par flux : la fin de la coordination centrale
La quatrième révolution a été la pensée produit, qui a mis l'accent sur la valeur plutôt que sur la conformité à un plan initial, et qui a enseigné que la seule façon de réellement savoir ce qui est précieux est d'expérimenter et d'apprendre des retours d'usage réels. Enfin, la cinquième révolution a été celle des équipes alignées par flux, popularisées notamment par les travaux sur le sujet : elle a encouragé les organisations à structurer leurs équipes pour qu'elles collaborent le moins possible entre elles afin de livrer leur code, réduisant la coordination inter-équipes à ce qui est strictement nécessaire.
Ensemble, ces cinq révolutions augmentent l'importance de l'architecture, il y a plus de décisions à prendre, plus souvent, dans plus d'endroits différents, tout en rendant intenables les approches centralisées traditionnelles avec lesquelles elle a longtemps été pratiquée. Un comité d'architecture qui se réunit toutes les deux semaines ne peut simplement pas absorber le volume de décisions que produit une organisation qui déploie en continu.
Le principe du conseil architectural : décider sans demander la permission
OV : Quand vous parlez de responsabiliser les développeurs, qu'est-ce que cela signifie concrètement ? Que feront-ils réellement ?
AHL : L'idée centrale du livre est que n'importe qui peut prendre n'importe quelle décision, à condition de demander conseil, mais pas la permission, à toutes les personnes concernées et à celles disposant d'une expertise pertinente.
Demander conseil, pas la permission
C'est extrêmement responsabilisant. Mais c'est aussi une augmentation significative de la responsabilité individuelle ; combiné à des enregistrements de décisions architecturales, cela crée également une forme de redevabilité. Pour les personnes qui souhaitent réellement décider, c'est un outil très puissant. Il y aura toujours des profils qui se concentrent sur l'architecture inter-équipes et à l'échelle du système, mais désormais les équipes peuvent aussi décider par elles-mêmes pour leur propre périmètre. Il en résulte une approche beaucoup plus dynamique, impliquée et engagée de la pratique architecturale, dans laquelle chacun a un intérêt direct au résultat.
Le rôle des ADR à l'ère des plateformes internes
En 2026, ce principe s'appuie sur un outillage devenu courant : enregistrements de décisions architecturales au format léger, historisés directement dans le dépôt de code à côté du code qu'ils concernent, publiés automatiquement sur le portail de développeurs interne de l'organisation, et de plus en plus résumés ou indexés par des assistants IA capables de retrouver « pourquoi telle décision a été prise » sans relire tout l'historique. Cet outillage ne remplace pas la conversation humaine du conseil architectural, mais il rend la trace de la décision consultable, cherchable et durable, condition nécessaire pour qu'un modèle décentralisé reste gouvernable à l'échelle de dizaines d'équipes.
Le nouveau rôle de l'architecte : coach plutôt que gardien
OV : Est-ce que les développeurs trouvent cela difficile, dans votre expérience ? Qu'est-ce que cela signifie pour les architectes logiciels ? Comment leur rôle évolue-t-il dans ce nouveau monde ?
AHL : Certains développeurs trouvent effectivement cela difficile. Mais le fait que le processus de conseil architectural permette à n'importe qui de décider ne signifie pas que tout le monde y est obligé.
Le livre s'adresse en réalité à deux audiences : d'abord, les développeurs expérimentés et les responsables d'équipe qui veulent entrer dans le monde de la décision architecturale ; ensuite, les architectes qui cherchent une nouvelle façon de pratiquer leur métier et de collaborer avec les autres. Il y a beaucoup à apprendre pour les développeurs lorsqu'ils ajoutent la prise de décision à leur pratique quotidienne, mais il y a tout autant à apprendre pour les architectes, qui peuvent devenir bien davantage des coachs, des guides, des communicants, des créateurs d'espace de discussion et, plus important encore, des initiateurs de conversation plutôt que des gardiens de la décision finale.
Cette évolution du rôle rejoint un mouvement plus large observé dans les organisations qui misent sur des architectures découplées et des frontières de service claires : moins l'architecte a besoin d'arbitrer chaque détail d'implémentation, plus il peut se concentrer sur les frontières, les contrats et les principes partagés qui permettent à chaque équipe de décider en autonomie dans son propre périmètre.
Construire la confiance : forums, principes partagés et radar technologique
OV : Qui est responsable de conduire ce changement ? Et quels en sont les risques ?
AHL : Je décris plusieurs approches possibles dans le livre. Le plus souvent, ce sont les architectes eux-mêmes qui l'impulsent, car ce sont eux qui détiennent initialement l'autorité de décider, et qui peuvent donc choisir de la redistribuer. Mais je décris aussi diverses stratégies que les équipes peuvent tenter dans le cadre de leurs processus hiérarchiques existants, pour tenter d'influencer ceux qui détiennent le pouvoir de les laisser expérimenter.
Le plus gros risque, cependant, est que la confiance n'ait pas le temps de s'établir et de se développer. Le processus de conseil architectural repose sur un contrat social implicite : « je te fais confiance pour décider judicieusement et pour consulter les bonnes personnes, et tu me fais confiance pour faire de même ».
Le forum de conseils architecturaux
Les enregistrements de décisions architecturales sont un excellent support à ce contrat, mais ils ne suffisent pas seuls. Un forum régulier de conseils architecturaux, une session récurrente et ouverte où les décisions en cours peuvent être présentées et challengées avant d'être actées, donne un espace explicite pour exercer ce droit de consultation sans ralentir le rythme de livraison quotidien.
Radar technologique et principes partagés
Un ensemble de principes architecturaux collectivement nourris, associé à un radar technologique qui collationne les retours d'expérience sur la meilleure façon de déployer une technologie ou une approche dans le contexte spécifique de l'organisation, complète ce dispositif. Ensemble, ces outils réduisent le coût cognitif de « bien décider » pour quelqu'un qui n'a pas quinze ans d'expérience en architecture, et rendent visibles les zones de couplage fort où une décision locale a plus de chances d'avoir un impact ailleurs dans le système.
Andrew Harmel-Law reste lucide sur les limites de l'exercice : la transition vers une nouvelle façon de distribuer le pouvoir décisionnel n'est jamais totalement indolore. C'est pourquoi le livre consacre plusieurs chapitres à la création de sécurité psychologique et d'inclusion, au leadership partagé, et à la manière de créer des « bulles » de processus de conseil expérimentales au sein de l'organisation, pour protéger l'équipe pendant que les pratiques sont encore fragiles et en cours d'apprentissage.
Une culture décisionnelle unique à chaque organisation
La culture exacte de prise de décision décentralisée qui émergera au sein d'une organisation sera toujours unique : elle dépend de ses collègues, de son paysage technologique, de ses clients, et de bien d'autres facteurs propres à son contexte. C'est précisément ce qui rend cette approche de la pratique architecturale à la fois exigeante et puissante : si on la laisse faire, elle s'adapte à l'organisation d'une manière qui répond spécifiquement à ses besoins, plutôt que d'imposer un modèle générique venu d'ailleurs.
Merci à Andrew Harmel-Law d'avoir pris le temps d'échanger avec nous sur ces questions.
Clause de non-responsabilité : Les déclarations et opinions exprimées dans cet article sont celles du ou des auteurs et ne reflètent pas nécessairement les positions d'Adservio.
RÉCUPÉRER CET ARTICLE
Téléchargez l'article complet en PDF pour le lire hors ligne ou le partager.
RESTER INFORMÉ
Recevez nos prochaines analyses et retours d'expérience directement dans votre boîte mail.
