Vers une architecture d’entreprise continue et exécutable : entretien avec William El Kaïm

Entretien réalisé pour Boldo.io, propos recueillis par Sylvain Melchior

Sylvain : William, merci de nous consacrer un peu de ton temps. Avant d’entrer dans le vif du sujet, peux-tu retracer pour nos lecteurs le parcours qui t’a mené à l’architecture d’entreprise ?

William : Ma carrière a commencé dans la recherche. Ma thèse portait sur la génération de code à partir de modèles. Puis je me suis tourné vers les lignes de produit logiciel, dont l’idée principale n’est pas de concevoir un logiciel unique, mais une famille de produits qui partagent un même socle. On modélise ce socle commun et ses points de variation, puis on génère le produit adapté à chaque client. C’est le prolongement direct de ma thèse : ce sont les modèles qui pilotent la génération. J’ai ensuite occupé des postes de conseil (dont huit ans au BCG) et d’architecte d’entreprise (Carlson Wagonlit Travel, Dalkia, Sanofi). Plus récemment, j’ai passé quelques mois chez SAP LeanIX comme expert produit, et je suis aujourd’hui directeur de l’architecture d’entreprise chez Pernod Ricard. Un fil traverse tout ce parcours : depuis des années, j’observe de près les outils de notre métier et j’ai suivi leur évolution. C’est ce qui m’a conduit à créer l’EA Codex.

Sylvain : Tu as donc observé la discipline depuis la recherche, le terrain et l’édition d’outils. De ce point de vue, quels sont les enjeux qui te paraissent aujourd’hui les plus structurants ?

William : Le premier enjeu tient au rôle même de l’architecte. Il reste mal défini, et il varie fortement selon la maturité et la taille de l’organisation. Selon les entreprises, on parle d’architectes IT, d’architectes métier (les business architects) ou de profils hybrides, capables de faire le pont entre les deux. Le second enjeu concerne les équipes d’architecture qui n’ont jamais formulé clairement leurs objectifs ; faute de les avoir posés, on ne les revoit pas et on ne les mesure pas. Au bout de trois ou quatre ans, les critiques fusent, mais personne ne dispose des éléments factuels pour en débattre sereinement. Le troisième enjeu naît de l’explosion du nombre de projets, souvent mal alignés avec le paysage applicatif. La donnée a déjà complexifié le tableau, et l’intelligence artificielle apportera bientôt une nouvelle strate. Les interlocuteurs se multiplient, et les discussions se mènent de front à plusieurs niveaux, de l’entreprise à la région jusqu’à l’équipe. La coordination en devient d’autant plus délicate. Encore faut-il disposer d’une connaissance constamment à jour, car on ne décide pas sur la foi d’un portefeuille déjà périmé. C’est tout l’intérêt d’un jumeau numérique : une vue du portefeuille rafraîchie quasiment en temps réel, qui évite de raisonner avec plusieurs mois de retard.

Sylvain : Nous nous sommes justement rencontrés autour d’un benchmark d’outils d’architecture. Comment lis-tu la trajectoire de ce marché ?

William : Je distingue trois approches. La première, l’approche outil du marché, consiste à acquérir un outil d’architecture d’entreprise existant et à faire mûrir sa pratique avec lui. La deuxième, à l’opposé, relève de l’artisanat, le craftsmanship : on renonce aux outils du marché pour bâtir soi-même sa solution, gérer sa propre vision du système d’information et, de plus en plus, la raccorder à la chaîne de développement. La troisième, enfin, regroupe les outils dits AI-native ou AI-first. Là, l’intelligence artificielle n’est pas une surcouche posée sur l’existant : elle est au fondement même de l’outil. Elle met en correspondance toutes les données, dans tous les formats, ce qui permet de construire un système qui ne se contente pas de décrire le portefeuille, mais qui raisonne et agit.

Sylvain : Cela conduit naturellement à ton initiative, l’EA Codex. Peux-tu nous en exposer l’idée directrice ?

William : L’idée directrice tient en une phrase : faire passer l’architecture d’une gouvernance documentaire et périodique à un système continu, sémantique, piloté par la spécification et réellement exécutable. C’est tout le propos de mon livre, AI-Augmented Enterprise Architecture. La chaîne se déroule de l’intention à la décision, puis à la spécification, à l’exécution et enfin au retour d’expérience qui vient nourrir la suivante. Jusqu’ici, l’architecte est resté cantonné à la documentation et à la gouvernance, sans jamais parvenir à suivre le rythme des changements et des projets. L’intelligence artificielle nous a donné l’occasion de créer un système exécutable pour piloter le processus de l’architecte lui-même. Je résume toujours ce processus en quatre temps : understand, manage, govern, execute. Comprendre ce que l’on possède, gérer le portefeuille, gouverner les standards et les règles, puis exécuter, car nous sommes de plus en plus proches du code. L’architecture cesse alors d’être un document : chaque décision, chaque standard, chaque spécification devient un objet relié aux autres dans un graphe. Certaines règles s’écrivent en clair, sous forme de policy as code : du code qui vérifie tout seul qu’un élément est conforme. Pour les cas qui demandent du jugement, on laisse l’IA raisonner. Les fitness functions complètent l’ensemble : ce sont des tests automatiques qui valident les exigences, surtout non fonctionnelles. Or ce sont justement elles qu’on néglige le plus, alors qu’elles causent l’essentiel des incidents en production. Aujourd’hui, les outils d’architecture ne gèrent presque pas ce corpus ; ils se contentent de décrire le portefeuille. Pourtant, dès qu’il faut absorber des changements continus, l’enjeu est d’appliquer les règles en temps réel, pas de les auditer tous les deux mois.

Sylvain : Si je te suis, cela revient à diffuser les règles d’architecture au cœur même des workflows de conception et de la chaîne CI/CD ?

William : Exactement. Prenons le principe du cloud first. Autrefois, je rédigeais un document expliquant ce qu’il recouvre et pourquoi il compte, je le publiais sur un SharePoint, et en design authority je me contentais de cocher « conforme » ou « non conforme ». Dans l’EA Codex, la démarche est autrement plus riche. On commence par décrire l’intention, puis on en dérive des règles exécutables : si l’on impose le cloud first, alors il faut vérifier la souveraineté, car il existe une dépendance directe entre les deux. La définition du principe traverse un processus comparable à celui qui valide du code, et elle produit en sortie un evidence record. J’ai automatisé cette design authority avec douze agents : un architecte solution, un architecte data, un architecte sécurité, et ainsi de suite. Le jour où j’ai soumis mon principe cloud first, persuadé qu’il passerait sans encombre, il a été bloqué. J’avais oublié des règles de sécurité et de pharmacovigilance, et l’agent sécurité a refusé de laisser passer un principe dépourvu de la moindre règle de sécurité. Le cycle se rejoue jusqu’à ce que chaque membre valide, et l’on peut régler le curseur du tout automatique jusqu’au tout humain. La vraie difficulté surgit au moment d’écrire les règles. C’est alors un autre métier : il faut réfléchir à la manière d’aller chercher l’information dans Boldo et déterminer précisément quelles règles formuler. On transforme en code ce qui ne vivait que dans la tête des experts. L’exercice est exigeant, mais une fois mené à bien, il devient remarquablement puissant : automatisé, réutilisable et sûr, parce que plus personne ne peut prétendre qu’il n’était pas au courant.

Sylvain : Tout cela augmente considérablement l’architecte. Quelle place reste-t-il alors pour l’humain ?

William : Son rôle va gagner en importance et en intérêt. Le drame de l’architecte, bien souvent, c’est de ne pas être écouté. Quand j’étais consultant, j’avais un test très simple : posez la même question à deux architectes ; si leurs réponses divergent, c’est qu’ils n’ont pas le même codex en tête. Les équipes projet l’ont parfaitement compris, et choisissent leur architecte en fonction de la réponse qu’elles espèrent. Parvenir à une vision partagée est déjà un acquis considérable. Concrètement, cette vision, c’est du contenu, des règles exécutables et un processus d’architecture d’entreprise prédéfini et exécutable, réunis dans le codex. Les architectes le construisent et le font évoluer ensemble, et raisonnent enfin tous à partir de la même référence. À l’intérieur de ce processus, chaque initiative suit un cycle court, le BMAD : Brief, Map, Act, Double-check. Plus on l’automatise, plus on tend vers une dark factory, où l’exécution se déroule presque sans intervention humaine. Le codex leur fait aussi gagner un temps précieux : au lieu de documenter pendant des heures, ils laissent la documentation se générer d’elle-même. Cet entretien, par exemple, pourrait être versé dans l’outil et enrichir la base de connaissances. L’architecte cesse alors d’être un gardien de portes pour devenir l’orchestrateur d’un processus de bout en bout. Beaucoup se sentent isolés ; ils accomplissent un travail remarquable, mais peinent à en faire reconnaître la valeur. Lorsque tout fonctionne, personne ne dit rien ; au moindre incident, ce sont eux que l’on désigne.

Sylvain : Tu reviens sans cesse sur deux notions, les fitness functions et l’evidence record. Pourquoi leur accordes-tu autant d’importance ?

William : Parce que ce sont les deux piliers d’une architecture qui se prouve. L’evidence record, d’abord : chaque décision, chaque vérification de règle laisse une trace horodatée, qui dit ce qui a été décidé, sur quelle base et par qui. On ne se contente plus d’affirmer qu’un système est conforme, on en apporte la preuve. C’est essentiel pour l’audit et la conformité réglementaire : des mois plus tard, on peut encore retrouver pourquoi une décision a été prise. La fitness function, ensuite, est un instrument décisif : c’est elle qui nous mène vers l’architecture as code et vers ce non-fonctionnel que les architectes maîtrisent mal, faute d’en avoir fait leur cœur de métier. On peut d’ailleurs partager ces fonctions d’un projet à l’autre. Elles se muent en règles : mon système doit être fiable, encore faut-il définir ce que « fiable » signifie. Une fois ces règles établies, le design s’unifie très vite et les coûts diminuent, puisqu’on cesse de réinventer à chaque projet une architecture déjà éprouvée.

Sylvain : Avant de conclure, quelles actualités aimerais-tu partager pour les prochains mois ?

William : J’ai mis tout ça en ligne, en open source : le livre et le schéma, avec un premier jeu d’objets, sont déjà disponibles. Je développe aussi un cockpit, une implémentation de référence open source, Git-native et sans base de données. Il me sert à vérifier que ce que j’ai en tête fonctionne. Il montre le Codex sous forme de carte : les objets d’architecture en nœuds, leurs relations en arêtes, et les quatre phases understand, manage, govern, execute comme fil conducteur. On y suit les deux graphes, le processus agentique qui les parcourt, et chaque décision y laisse son evidence record. Ce qui me ferait plaisir, c’est que des praticiens reprennent ces idées pour étendre leurs propres outils avec ce codex, ou que des éditeurs comme toi en intègrent quelques concepts. On aurait alors un graphe de connaissances élargi : d’un côté l’infrastructure et les applications réelles, de l’autre la gouvernance automatisée. Pour les data products, par exemple, il existe déjà des standards pour décrire un data product ou un data contract ; pas besoin de réinventer la roue. Il suffit de donner aux architectes des outils qui rendent ces idées concrètes, parce qu’ils n’auront jamais le temps de créer les leurs.

Sylvain : Parmi tout ce que tu décris, quelle capacité ces outils devraient-ils, selon toi, adopter en premier ?

William : Sans hésiter, la design authority automatisée et agentique. C’est la brique que tout outil d’architecture devrait commencer à proposer. On peut démarrer modestement, avec une poignée de principes validés qui génèrent chacun leur evidence record, puis monter en puissance. Au cœur, c’est un processus qui parcourt les deux graphes, raisonne et agit. L’IA ne remplacera pas l’architecture ; elle la rend explicite et obligatoire. Toute décision d’architecte doit devenir un objet que l’on gouverne, et non une simple phrase enfouie dans un document. Et un agent ne saurait se contenter d’un prompt : il lui faut un contrat. Car ce qui sépare une application d’un agent, c’est que l’agent décide et agit de lui-même ; il revient à l’architecte de fixer ce qu’il a le droit de faire, sous peine de ne plus savoir ce qu’il fera. Cette brique s’inscrit dans une logique plus large, celle de l’architecture continue, avec l’amélioration continue qui va avec : chaque fois que l’on apprend quelque chose, on s’épargne de répéter la même erreur. Or les outils d’aujourd’hui excellent dans le understand et le manage, beaucoup moins dans le govern et dans son articulation avec l’execute. C’est exactement la faille que l’EA Codex vient combler, comme une couche ouverte que ces outils peuvent adopter au lieu de la réécrire chacun dans son coin. Le jour où l’on relie tous ces éléments, l’outil change de dimension, et ce n’est pas hors de portée : en deux ou trois semaines, on bâtit une extension réellement utile. Un outil comme Boldo me paraît bien placé pour cela, parce qu’il est lean tout en permettant de créer vite. Reste la vraie question, celle de la valeur : pourquoi investir dans de l’architecture exécutable, sur quel périmètre et pour quel retour. Si la capacité vient avec l’outil, je n’hésite pas ; si je dois la coder moi-même, je réfléchis davantage, car écrire du code, c’est aussi créer de la dette.

Sylvain : Merci infiniment, William, pour ta disponibilité et pour la richesse de cet échange.

William : Merci à toi pour l’invitation, ce fut un vrai plaisir. Le métier est en pleine expansion : les postes d’architectes se multiplient, et beaucoup d’architectes solution vont évoluer vers l’architecture d’entreprise. Cette dynamique va créer de la valeur, mais elle change aussi les attentes : on demandera à l’architecte de prouver cette valeur, pas seulement de l’affirmer. C’est justement là que la profession reste fragile, car les architectes savent rarement justifier leurs investissements auprès de leur DSI. D’où l’intérêt d’outils, même simples, qui rendent cette valeur visible et démontrable. C’est, à mes yeux, la bonne direction : faire de chaque décision d’architecture quelque chose que l’on peut montrer, mesurer et défendre.

Pour découvrir l’EA Codex et le livre AI-Augmented Enterprise Architecture, rendez-vous sur le site compagnon https://eacodex.ai/. Le schéma d’objets est en open source sur https://github.com/welkaim/ea-codex.

Pour découvrir Boldo, rendez-vous sur https://boldo.io.