Introduction

Une version de cette conversation se déroule en ce moment même dans les salles de réunion de toute la France. Un DSI arrive avec une feuille de route construite autour de la consolidation cloud, de la modernisation des API et de l’intégration progressive de l’IA. Le comité de direction repousse : où sont les résultats en IA ? Pourquoi la concurrence avance-t-elle plus vite ? La réponse honnête, celle qu’on dit rarement à haute voix, est que l’architecture sous-jacente à l’ambition IA n’a jamais été conçue pour la soutenir.

Ce n’est pas un échec de vision. C’est un décalage structurel. Les systèmes d’information qui alimentent la plupart des organisations françaises établies ont été construits pour une autre époque : des charges de travail stables, des flux de données prévisibles, des cycles de décision avec intervention humaine. Le développement natif IA casse chacune de ces hypothèses. Il exige des pipelines de données en temps réel, une allocation dynamique du calcul, une orchestration multi-agents et des cadres de gouvernance qui n’existaient pas il y a trois ans.

L’écart entre le point où se situent la plupart des architectures IT aujourd’hui et celui où les opérations natives IA les exigent n’est pas un écart que vous fermez avec un sprint. Il nécessite une refonte structurelle délibérée et dirigée par des experts. Cet article explique à quoi ressemble cette refonte, pourquoi elle dépasse la capacité de la plupart des équipes internes et quel est le coût réel du retard.

1. L’écart architectural que personne ne discute ouvertement

Les projections de Gartner pour 2026 sont sans équivoque : d’ici 2030, 80 % des grandes équipes logicielles seront augmentées par l’IA, et 40 % des applications d’entreprise seront construites sur des plateformes natives IA contre seulement 2 % aujourd’hui. Ce n’est pas un changement progressif. C’est un remplacement quasi complet du modèle de développement et opérationnel sur lequel s’appuient actuellement la plupart des organisations.

Le problème est que la plupart des responsables IT tentent de combler cet écart en superposant des capacités IA à l’architecture existante. Un copilote ici, un module d’apprentissage automatique là, une connexion API à un modèle de fondation. Cela ressemble à du progrès sur une diapositive. En pratique, cela crée de la fragilité. Les pipelines de données sous-jacents n’ont pas été conçus pour le volume, la vélocité ou la variabilité que les charges de travail IA génèrent. Le périmètre de sécurité n’a pas été construit pour gérer les agents autonomes prenant des décisions et déclenchant des actions. Le modèle de gouvernance suppose un examen humain à chaque étape, un modèle qui s’effondre sous l’IA agentique.

Le cadre MAGNum 2026, publié en mars 2026 par L’Usine Digitale, identifie explicitement ce désalignement structurel. Ses treize vecteurs de gouvernance, couvrant l’architecture, les données et l’IA, le risque et la conformité, et la gestion de portefeuille, reflètent une reconnaissance que le SI n’est plus une fonction de support. C’est le cœur stratégique de l’organisation. Le concevoir comme s’il s’agissait encore d’une fonction de back-office n’est pas seulement une erreur technique. C’est une erreur stratégique.

Ce qui rend cela particulièrement difficile est que l’écart est invisible jusqu’à ce que quelque chose se casse. Les équipes livrent des fonctionnalités IA, les démos fonctionnent, les pilotes réussissent. Ensuite, le système atteint l’échelle de production et les fissures apparaissent : pics de latence, incohérences de données, expositions de conformité, dépassements de coûts sur le calcul. À ce stade, les décisions architecturales qui ont causé le problème ont été prises des mois plus tôt, et les défaire est coûteux.

2. Qu’est-ce que « natif IA » exige réellement de votre infrastructure ?

Natif IA n’est pas une étiquette marketing. Cela décrit un ensemble spécifique d’exigences architecturales qui diffèrent fondamentalement de la conception IT d’entreprise traditionnelle. Comprendre ces exigences est la première étape vers une évaluation honnête de la position de votre système actuel.

Au niveau de la couche données, les systèmes natifs IA exigent des flux de données continus et de haute qualité, pas des exports par lots ou une synchronisation périodique. Les modèles ont besoin d’accès à des données fraîches et contextualisées en quasi temps réel. Cela signifie repenser les pipelines ETL, les contrats de données entre systèmes et la gouvernance de la qualité des données à la source. Selon les conclusions du CIO Summit France d’IDC, l’architecture, les données et la gouvernance sont les trois angles morts les plus responsables des déploiements IA échoués dans les environnements d’entreprise. Ce n’est pas une coïncidence : ce sont exactement les couches que l’architecture IT traditionnelle traite comme des préoccupations secondaires.

Au niveau de la couche calcul, les charges de travail IA sont fondamentalement non linéaires. Un seul flux de travail agentique peut augmenter la demande de GPU d’un ordre de grandeur en quelques secondes, puis chuter à près de zéro. L’approvisionnement en infrastructure statique, le modèle par défaut pour la plupart des environnements sur site et hybrides, ne peut pas gérer cela avec élégance. Les organisations qui n’ont pas migré vers une allocation de calcul dynamique et pilotée par des politiques paient pour une capacité qu’elles n’utilisent pas et ne parviennent pas à fournir la capacité quand elles en ont besoin.

Au niveau de la sécurité et de la gouvernance, le défi est encore plus complexe. Les systèmes IA agentiques, où les modèles prennent des actions autonomes, appellent des API externes, écrivent dans des bases de données et déclenchent des processus en aval, exigent un modèle de gouvernance qui suit l’identité, les permissions et les actions au niveau de l’agent. La loi IA, pleinement applicable à partir du 2 août 2026, impose exactement ce type de traçabilité. Comme l’a noté Frédéric Brajon de Saegus, « de nombreuses organisations n’ont pas encore de gouvernance centralisée capable de maintenir une vue exhaustive de tous les systèmes IA déployés, qu’ils soient construits en interne, achetés ou intégrés ». C’est une exposition de conformité, pas seulement un écart technique.

Gartner encadre l’évolution du rôle du DSI autour de trois archétypes : l’Architecte qui construit des fondations natives IA, le Synthétiseur qui transforme les systèmes multi-agents en résultats commerciaux mesurables, et la Sentinelle qui assure la confiance, la souveraineté et la sécurité préventive. La plupart des organisations IT fonctionnent actuellement dans aucun de ces modes avec une quelconque cohérence.

3. Pourquoi les équipes internes atteignent systématiquement le plafond

C’est la partie la plus difficile à dire directement, mais l’expérience de terrain la rend inévitable : les équipes responsables du maintien de votre architecture actuelle sont souvent les moins bien positionnées pour la redessiner. Non pas parce qu’elles manquent de talent, ce n’est pas le cas. Mais parce qu’elles sont entièrement engagées à maintenir le système existant en fonctionnement, et parce que l’expertise requise pour la refonte architecturale native IA est véritablement rare.

Le Baromètre de l’obsolescence des compétences IT (Journal du Net, janvier 2026) chiffre cela : 53 % des DSI identifient la cybersécurité comme le domaine le plus exposé à l’obsolescence des compétences, suivi par l’IA à 49 % et la gestion des données à 30 %. Ce ne sont pas des domaines périphériques. Ce sont les compétences exactes requises pour concevoir et exploiter une architecture native IA. Et 69 % des DSI considèrent l’accès aux compétences comme un défi majeur, selon les données McKinsey citées par Journal du Net.

Le problème structurel va plus profond que l’embauche. Même les organisations qui recrutent agressivement pour les talents en IA et en ingénierie des données constatent que ces profils, quand ils existent, sont absorbés par la livraison de projets plutôt que par la conception architecturale. Il y a une différence entre un ingénieur qui implémente une fonctionnalité sur une plateforme IA et un architecte qui conçoit la plateforme elle-même, définit les contrats de données, établit le modèle de gouvernance des agents et assure que tout le système est auditable selon la loi IA. Ce dernier profil est rare, coûteux et généralement indisponible sur le marché des effectifs permanents.

C’est la dynamique qui conduit à la situation que Penon Partners rencontre le plus fréquemment : une organisation IT qui a fait des progrès réels sur l’adoption de l’IA, mais dont l’architecture sous-jacente n’a pas suivi le rythme. L’équipe a fait ce qu’elle pouvait avec les ressources et l’expertise disponibles. L’écart n’est pas un échec d’effort, c’est un échec de capacité structurelle. Comme nous l’avons exploré en détail dans notre analyse de pourquoi les projets IA échouent et ce que l’expertise externe peut corriger, la cause première est presque toujours architecturale plutôt que technologique.

4. Comment savez-vous que votre architecture actuelle bloque activement la valeur IA ?

Les symptômes sont reconnaissables, même si le diagnostic n’est pas toujours immédiat. Voici les modèles qui signalent systématiquement une architecture qui a dépassé sa conception.

Premièrement : les pilotes IA réussissent, les déploiements en production échouent. L’environnement pilote est contrôlé, les données sont propres, le périmètre est étroit. La production introduit une complexité du monde réel : problèmes de qualité des données, défaillances d’intégration, latence sous charge, exceptions de sécurité qui bloquent les actions des agents. Si vos projets IA réussissent systématiquement dans des conditions contrôlées et peinent à l’échelle, l’architecture est la contrainte.

Deuxièmement : votre gouvernance des données ne peut pas répondre à des questions élémentaires sur vos systèmes IA. Selon les exigences de la loi IA, vous devez savoir, pour chaque système IA en opération, quelles données il utilise, quelles décisions il influence, quel niveau d’autonomie il possède et qui en est responsable. Selon l’étude CGI 2025 « Voice of Our Clients », seulement 41 % des décideurs rapportent que leurs stratégies numériques produisent les résultats attendus. Une part importante de cet écart remonte à l’incapacité à gouverner les systèmes IA au niveau organisationnel, pas seulement au niveau technique.

Troisièmement : vos coûts de calcul sont imprévisibles et croissent plus vite que votre valeur IA. C’est un signal direct d’une infrastructure qui n’a pas été conçue pour les modèles de charge de travail IA. L’approvisionnement statique, la mise à l’échelle manuelle et l’absence de suivi du coût par inférence sont des choix architecturaux, et ils ont des conséquences financières qui se composent rapidement à mesure que l’utilisation de l’IA augmente.

Quatrièmement : votre équipe de sécurité opère de manière réactive sur les risques IA plutôt que de manière proactive. Les 504 000 demandes d’incidents de cybersécurité enregistrées par Cybermalveillance.gouv.fr en 2025, combinées à une augmentation de 38 % des cyberattaques contre les organisations françaises (ANSSI), reflètent un environnement où les systèmes IA, avec leur surface d’attaque étendue et leurs capacités d’action autonome, exigent une conception architecturale de sécurité proactive, pas une réponse aux incidents.

Si deux ou plus de ces modèles sont présents, l’architecture n’est pas une préoccupation de fond. C’est un bloqueur actif. Ceci est cohérent avec ce que nous avons documenté dans notre analyse plus large de la transformation numérique en France en 2026 : les organisations qui font des progrès réels sont celles qui ont d’abord abordé les fondations architecturales, pas en dernier.

5. À quoi ressemble réellement le leadership architectural externe en pratique

Le leadership architectural externe n’est pas un synonyme d’externalisation. C’est un modèle d’engagement spécifique : un architecte senior avec une expérience éprouvée des plateformes natives IA s’intègre au sein de l’organisation, travaille aux côtés de l’équipe interne et dirige la refonte structurelle tout en transférant les connaissances et les capacités dans toute l’organisation.

La valeur ne réside pas dans les livrables : les diagrammes, les cadres, la documentation. La valeur réside dans les décisions prises correctement la première fois. Un architecte qui a conçu des pipelines de données natifs IA dans des contextes d’entreprise comparables sait où se trouvent les modes de défaillance avant qu’ils n’apparaissent. Il sait quels choix de gouvernance créeront des problèmes de conformité à la loi IA à l’échelle. Il sait comment concevoir des politiques d’allocation de calcul qui restent prévisibles en coûts à mesure que l’utilisation de l’IA augmente. Cette reconnaissance de modèles ne se construit pas en interne en six mois : elle provient d’avoir déjà fait cela, dans des environnements de production réels, sous une pression réelle.

98 % des entreprises françaises devraient augmenter leurs budgets IA en 2026 (Journal du Net, janvier 2026). Cet investissement sera gaspillé si les fondations architecturales ne sont pas en place pour le soutenir. Le constat de l’étude CGI, que seulement 41 % des décideurs numériques obtiennent les résultats attendus de leurs stratégies numériques, reflète exactement cette dynamique. L’investissement technologique sans préparation architecturale ne produit pas de résultats. Il produit de la complexité.

Chez Penon Partners, les engagements qui offrent la valeur la plus claire sont ceux où l’architecte externe est amené au stade de la conception, pas au stade du sauvetage. Le mandat est spécifique : évaluer l’architecture actuelle par rapport aux exigences natives IA, identifier les écarts structurels, concevoir le chemin de transition et diriger la mise en œuvre avec l’équipe interne. Ce n’est pas une mission de conseil qui se termine par un rapport. C’est un engagement opérationnel qui se termine par un système qui fonctionne, et une équipe qui comprend pourquoi. C’est le type de transformation structurelle que nous décrivons dans notre analyse de pourquoi la transformation n’est plus un projet mais une discipline continue.

Les organisations les mieux positionnées pour cet engagement sont celles où le leadership a déjà reconnu que le plafond de capacité interne a été atteint : où la pression est réelle, le budget est alloué et le besoin est un partenaire avec la crédibilité et l’adéquation situationnelle pour réduire la pression plutôt que de l’ajouter.

Conclusion

Le passage à une architecture native IA n’est pas une préoccupation future. C’est un défi structurel présent avec une date limite réglementaire stricte : l’application complète de la loi IA en août 2026, et un coût compétitif qui se compose à chaque trimestre de retard. Les organisations qui extrairont une valeur réelle de l’IA au cours des trois prochaines années ne sont pas celles ayant les plus grands budgets IA. Ce sont celles qui ont redessiné leurs fondations architecturales avant de mettre à l’échelle le déploiement.

Cette refonte nécessite une expertise que la plupart des équipes internes ne possèdent pas actuellement, non pas parce qu’elles ne sont pas capables, mais parce que les compétences sont véritablement rares et l’équipe interne est déjà entièrement engagée à maintenir les systèmes existants en fonctionnement. Le cas du leadership architectural externe ne concerne pas la méfiance envers les talents internes. Il s’agit d’honnêteté structurelle : certains problèmes exigent un profil qui n’existe pas dans vos effectifs permanents, et le coût de prétendre le contraire se mesure en déploiements échoués, expositions de conformité et perte de terrain compétitif.

Si vos initiatives IA produisent des pilotes mais pas des résultats en production, si votre gouvernance ne peut pas répondre à des questions élémentaires sur vos systèmes IA, ou si vos coûts de calcul croissent plus vite que votre valeur IA, l’architecture est la contrainte. Le bon mouvement est de l’aborder directement, avec l’expertise appropriée, avant que l’écart ne s’élargisse davantage.