Le rôle des architectes d’entreprise pour réussir la mise à l’échelle de l’IA dans l’organisation

Multiplier les expérimentations IA sans se poser la question de l’architecture, c’est prendre le risque d’ajouter de la complexité là où l’on espère créer de la valeur. Assistants métiers, copilotes, automatisation de décisions… Les cas d’usage se multiplient, mais la vraie question pour les DSI et directions de la transformation reste la même : comment intégrer ces briques IA dans un système d’information déjà dense, sans perdre en lisibilité, en maîtrise des risques et en alignement stratégique ?

C’est précisément le quotidien de Daniel, consultant architecte d’entreprise chez Projexion. Il est actuellement en mission en tant qu’architecte d’entreprise pour un géant du retail, avec un rôle clair : garantir la cohérence du système d’information entre les besoins métiers, les choix de solutions et les principes d’architecture de l’entreprise. Rattachée à la DSI et très proche des métiers, l’équipe d’architecture joue ce rôle de coordonnateur : aligner les initiatives, vérifier leur compatibilité avec la trajectoire cible, et s’assurer que chaque projet contribue vraiment à la stratégie d’ensemble.

Daniel coordonne également l’axe d’exploration IA au sein de Projexion, pour structurer notre veille, partager nos convictions, capitaliser les retours d’expérience et tester des cas d’usage IA en lien avec nos expertises.

Dans cet entretien, il revient sur une question centrale pour beaucoup d’organisations : quel rôle pour les architectes d’entreprise lorsqu’il s’agit de mettre l’IA à l’échelle, au-delà des POC ?

Pourquoi l’architecture d’entreprise devient-elle un sujet central dès que l’on parle d’IA dans une organisation ?

Pour moi, l’architecture d’entreprise devient centrale dès que vous parlez d’IA parce qu’elle est le seul cadre qui relie vraiment stratégie d’entreprise, processus métiers, données et système d’information. L’efficacité de l’IA repose sur trois piliers : la qualité des données disponibles, la clarté des usages ciblés et la maturité des capacités techniques en place. Si vous déployez des solutions IA sans vous appuyer sur l’architecture d’entreprise, vous fabriquez très vite des briques isolées qui se superposent à l’existant, augmentent la dette technique et créent plus de complexité que de valeur.

Notre rôle, en architecture, c’est aussi de poser les pré-requis : identifier les flux de données nécessaires, déterminer où les collecter, garantir leur sécurisation et choisir les plateformes techniques alignées avec la stratégie de l’entreprise. L’IA vient percuter en même temps le juridique, la conformité, la sécurité, les données, les métiers… Le métier veut aller vite, la DSI doit garantir la robustesse et la maîtrise des risques. En tant qu’architectes d’entreprise, nous sommes au milieu : nous coordonnons, nous arbitrons, nous vérifions la cohérence, nous validons la pertinence des cas d’usage par rapport à la trajectoire globale.
Ce qui change aussi avec l’IA, c’est le point de départ des initiatives, leur nombre et la pression du marché. Un service Cloud est souvent d’abord impulsé par la DSI. L’IA, elle, est vécue au quotidien par les métiers, qui voient immédiatement des usages et veulent être en première ligne. Dans ce contexte, l’architecture d’entreprise devient le garde-fou qui limite le Shadow IT, et qui s’assure que l’IA n’est pas juste un gadget de plus, mais une brique qui s’intègre proprement dans le système et contribue réellement à la création de valeur.

Sans architecture d’entreprise, l’IA ajoute souvent plus de complexité qu’elle ne crée de valeur !

À quel moment l’architecte d’entreprise devrait-il arriver dans les initiatives IA ?

D’expérience, dans beaucoup d’organisations, l’architecte d’entreprise arrive encore trop tard dans les projets liés à l’IA. Nous sommes sollicités au moment des POC, voire au moment où l’on commence déjà à parler mise à l’échelle. À ce stade, les usages sont définis, certaines briques techniques sont choisies, parfois même engagées contractuellement. Le rôle de l’architecte devient alors essentiellement correctif : remettre de la cohérence entre des initiatives éparpillées, limiter la dette technique générée, essayer de reconnecter l’ensemble à la trajectoire du SI et à la stratégie d’entreprise.

Idéalement, nous devrions être impliqués en amont, au moment où se construisent la roadmap IA, la priorisation des cas d’usage et la gouvernance. C’est là que nous pouvons évaluer la réalité des capacités nécessaires : qualité et fraîcheur des données (il n’y a pas d’IA exploitable sans données fiables), maturité et stabilité des processus (sont-ils documentés, automatisables ?), niveau de dette technique et structurelle (monolithe, microservices, intégrations historiques…), choix de plateforme, mais aussi capacité organisationnelle et compétences disponibles.

Si la dette supplémentaire créée par un cas d’usage IA est supérieure aux bénéfices attendus, il vaut mieux commencer par traiter les causes de cette dette.

Les conséquences d’une arrivée trop tard sont très concrètes : redondance d’outils, difficultés à industrialiser des POC pensés hors contexte, voire projets remis en cause après plusieurs mois d’effort. J’ai en tête un cas dans le domaine de la création de collections : le métier voulait optimiser la productivité du design produit et a choisi seul un outil génératif à partir de descriptifs. Résultat : des designs impossibles à réutiliser dans les autres outils, et non conformes aux principes de valeur et à la charte de l’entreprise. Quand l’architecture a été sollicitée, une partie du projet était déjà engagée ; il a fallu revenir en arrière sur plusieurs décisions, et discuter sérieusement de l’arrêt du dispositif.

Appliquée à un processus instable, l’IA n’apporte pas d’accélération : elle amplifie le chaos.

Qu’est-ce que l’Agentic AI change dans la façon de penser la Business Architecture ?

L’Agentic AI change profondément la manière de concevoir la business architecture parce qu’il ne s’agit plus seulement d’optimiser des tâches, mais d’introduire un nouvel acteur dans l’organisation. Un agent capable de percevoir une situation, de décider et d’agir ne se traite pas comme un simple outil : il prend des décisions intermédiaires, déclenche des actions, coordonne des systèmes. À partir de là, la Business Architecture ne peut plus se limiter à cartographier des chaînes d’activités et des rôles humains, elle doit intégrer ces agents comme des parties prenantes à part entière.

Concrètement, cela oblige à repenser les processus métiers. Ils ne sont plus strictement séquentiels ni systématiquement validés par un humain à chaque étape. La Business Architecture doit préciser qui fait quoi, quand, et avec quel niveau de contrôle : quelles décisions sont déléguées à l’agent, dans quelles limites, avec quelles règles de décision, quels points de passage obligés vers l’humain, quelles conditions d’escalade. L’agent devient une capacité métier à part entière, avec ses compétences cognitives, sa capacité d’action (exécuter des tâches) et sa capacité de collaboration avec les humains.

Cela conduit vers une forme de Business Architecture augmentée, où l’IA est intégrée au même titre que les collaborateurs. Mais cette symétrie apparente ne dispense pas du cadre : un agent IA doit être gouverné, tracé, contrôlé. Il faut définir ses périmètres d’autonomie, les registres dans lesquels il a le droit d’agir, les logs qui permettent de comprendre ses décisions, et les garde-fous qui garantissent que la responsabilité finale reste bien humaine.

Avec l’Agentic AI, la Business Architecture doit traiter l’agent comme un acteur du métier, mais un acteur dont l’autonomie est précisément cadrée.

Comment positionnez-vous alors la Business Architecture « au centre du jeu » pour que les politiques métier gouvernent réellement l’action de ces agents IA ?

Pour que les politiques métier gouvernent réellement l’action des agents IA, il faut remettre la Business Architecture au centre du jeu en tant que cadre opérationnel. Concrètement, cela veut dire définir les règles du jeu : les agents ne doivent pas improviser, ils doivent opérer à l’intérieur de politiques métiers claires, de priorités opérationnelles explicites et d’un niveau d’autonomie défini. C’est la Business Architecture qui formalise ce cadre : quelles sont les règles métier, dans quel ordre elles s’appliquent, avec quels objectifs, et jusqu’où un agent a le droit d’aller sans repasser la main à un humain.

La Business Architecture a aussi un rôle clé pour définir les capacités métiers sur lesquels les agents s’appuient. Un agent IA ne remplace pas le métier, il amplifie certaines capacités existantes. Nous devons donc identifier les capacités métier actuelles, celles qu’il est pertinent d’amplifier via l’IA, et celles où l’humain doit rester au centre pour des raisons de risque, de jugement ou de relation client. À partir de là, nous redessinons les processus pour intégrer les agents comme de vrais acteurs : points d’entrée et de sortie, types de décisions qu’ils peuvent prendre, échanges d’information avec les équipes, et conditions d’escalade. Enfin, cette position « au centre » ne tient que si la gouvernance suit. Il faut prévoir les canaux de supervision, la mesure de la performance des agents, le suivi du ROI, mais aussi les mécanismes de correction si l’agent dérive par rapport aux attentes métier. C’est cette articulation entre règles, capacités, processus et gouvernance qui permet au métier de rester aux commandes, tout en tirant pleinement parti de l’autonomie des agents IA.

Un agent IA ne doit pas inventer son métier : c’est à la Business Architecture de lui donner des règles, un rôle, des capacités à exploiter ou amplifier et des limites claires.

Cette montée en puissance de l’IA fait-elle évoluer le rôle de l’architecte d’entreprise ?

Oui, clairement, l’architecte d’entreprise devient un acteur politique. Nous nous situons au carrefour des tensions : les métiers veulent aller vite, la DSI veut de la robustesse, le juridique veut du contrôle, le Risk ou la Compliance veulent des garanties. Ces visions peuvent diverger fortement autour de l’IA, et quelqu’un doit assumer le rôle de médiateur pour aligner les directions autour d’une trajectoire commune.

Dans ce contexte, l’architecte d’entreprise rapproche les objectifs, identifie les compromis possibles et formalise la cohérence globale. Nous sommes l’un des rares acteurs à avoir une vision transversale : nous comprenons à la fois les dépendances techniques, les contraintes de réglementation, les usages métiers, les risques. Cela nous permet de reformuler les demandes, de les éclairer et de proposer un chemin qui respecte les différents enjeux sans sacrifier la cohérence du système d’information.

En pratique, dans ma mission actuelle, ce rôle politique s’exerce au sein d’un comité d’urbanisation qui regroupe des profils variés. Les acteurs métiers comme DSI viennent avec leurs besoins et leurs enjeux. Ensemble, nous instruisons la demande, nous l’analysons au regard des principes d’architecture — partagés par tous, ce qui facilite les arbitrages — et nous formulons des préconisations. Ce ne sont jamais des ordres, mais des décisions collégiales éclairées par une vision d’ensemble, que nous synthétisons ensuite pour les partager à l’organisation !

Entre métiers, DSI et juridique, l’architecte d’entreprise devient le médiateur qui transforme des tensions en décisions cohérentes.

Quelle lecture des contraintes et gains est indispensable avant d’injecter de l’IA et comment la transformer en décision d’investissement ?

Avant d’injecter de l’IA dans un périmètre, je commence par une lecture structurée des contraintes et des gains, avec des critères définis précisément en fonction du contexte et de la stratégie d’entreprise. Côté valeur, il s’agit de mesurer l’impact sur les objectifs métiers : quels KPI va-t-on vraiment déplacer, quels irritants ou quels enjeux stratégiques l’initiative adresse. Côté contraintes, je regarde les risques techniques et opérationnels (maintenabilité, sécurité, robustesse), la qualité des données (fiabilité des inputs, conformité réglementaire), ainsi que les coûts et ressources nécessaires pour développer, intégrer et opérer la solution dans la durée.De nombreux retours d’expérience, notamment ceux du Cigref sur la mise en œuvre de l’IA en entreprise, confirment l’importance de cadrer ces initiatives avec une gouvernance solide et des critères d’évaluation explicites.

Cette lecture est ensuite transformée en grille d’évaluation pondérée. Les critères ressemblent beaucoup à ceux utilisés pour d’autres projets, mais avec des spécificités IA : une attention plus forte portée aux données, aux risques et parfois à l’éthique, qui pèsent davantage dans la décision. Chaque initiative IA est scorée, et des seuils sont définis pour décider si le projet peut avancer, doit être retravaillé ou n’est pas prioritaire. Comme nous travaillons souvent en mode agile, ces critères et leurs pondérations ne sont pas figés : ils peuvent évoluer au fil des retours, avec des jalons où l’on décide de continuer, d’ajuster ou d’arrêter.

En RUN, pour le pilotage du portefeuille d’initiatives IA, je ne vois pas de rupture méthodologique majeure par rapport aux autres portefeuilles de projets. Ce qui change, ce sont surtout les indicateurs suivis et la sensibilité sur certains axes, pas la logique de pilotage en tant que telle.

Nous parlons beaucoup de révolution apportée par l’IA. Cependant, au niveau des décisions d’investissement, il n’y a pas de rupture : les bonnes pratiques restent valables, à condition de les adapter.

Quelles seraient vos trois règles pour « intégrer l’IA sans casser l’entreprise » ?

La première règle, c’est de ne pas partir de l’IA, mais du problème métier. La plus grande erreur, c’est de vouloir tout révolutionner d’un coup parce qu’une nouvelle technologie arrive. L’IA n’est pas un objectif en soi. Il faut partir des irritants, de la réalité du terrain, des besoins métiers concrets. Quel problème veut-on vraiment résoudre, pour qui, dans quel contexte ? C’est seulement à partir de là qu’on peut se demander si l’IA apporte une réponse pertinente, et sous quelle forme.

La deuxième règle, c’est de garder l’humain au centre. Une IA aussi puissante soit-elle ne sert à rien si elle est mal utilisée, ou si elle ne s’inscrit pas dans un usage clair. La conduite du changement, l’acculturation, l’adoption font partie intégrante des clés de succès. Qui va utiliser l’outil, avec quelles compétences, quelles craintes, quels impacts sur les métiers existants ?

La troisième règle, c’est de poser un cadre de gouvernance et d’éthique clair. L’IA ne doit pas être déployée sans règles ni maîtrise. Sans ce cadre, vous ouvrez la porte à des effets de bord : biais ou discriminations dans les processus de recrutement, nouvelles failles de sécurité, non-respect du RGPD, atteintes à l’image de marque… Au fond, comme pour toute technologie, les questions restent les mêmes : quelle valeur apportée, quels risques, quel retour sur investissement. Avec le recul, vous finissez par voir l’IA comme une technologie parmi d’autres : elle fait évoluer certaines pratiques, en renforce d’autres, mais elle ne rend pas obsolètes toutes les méthodes de gestion de portefeuille ou d’architecture existantes. L’enjeu, c’est de savoir les adapter là où données, risques et éthique prennent plus de poids.

Intégrer l’IA sans casser l’entreprise, c’est croiser métier, compréhension technologique, architecture, projet et accompagnement humain plutôt que courir derrière le dernier effet de mode.

Chez Projexion, nous disposons d’un ADN autour de l’architecture d’entreprise, la formation et le management de projet. Vis-à-vis de l’IA, nous ne cherchons pas à devenir un pure player : nous intégrons l’IA dans nos pratiques actuelles et dans la compréhension des contextes de nos clients. Avec nos expériences, nous intervenons sur des projets IA qui mobilisent nos expertises : cadrage, architecture d’entreprise, gestion de projets et de portefeuilles. L’IA soulève aussi beaucoup d’enjeux de formation et d’adoption – y compris via des Serious Games – qui font déjà partie du socle de nos accompagnements.

Pour conclure, vous ne tirez vraiment parti de l’IA que lorsque sa maîtrise technique rencontre l’architecture, le pilotage de projet, la formation et la conduite du changement. C’est cette combinaison que nous travaillons avec vous chez Projexion !