Pourquoi l'IA générative est-elle mal adaptée au traitement automatique des flux de données d'entreprise ?

Un LLM est un moteur probabiliste de génération de texte. Entraîné sur des corpus massifs, il excelle à comprendre une question, synthétiser des documents, rédiger, traduire ou coder. Ce qu'il ne sait pas faire nativement, c'est interroger une base de données relationnelle en temps réel, réconcilier des référentiels hétérogènes, ou garantir la cohérence d'un flux transactionnel entre un ERP comme SAP S/4HANA et un CRM comme Salesforce. Quand on lui demande de raisonner sur des données métiers, il a besoin qu'on les lui fournisse proprement, structurées, dédupliquées, contextualisées, ce que la plupart des SI d'entreprise ne sont pas en mesure d'offrir.

La conséquence est directe : l'IA ne corrige pas la mauvaise qualité des données, elle l'amplifie. Un modèle qui ingère des données clients contradictoires entre deux systèmes produit des recommandations qui le sont tout autant. Le principe du garbage in, garbage out s'applique avec une brutalité particulière aux LLM, parce que leur capacité à produire du texte fluide et convaincant masque les erreurs de fond. L'hallucination n'est pas qu'un problème de modèle : c'est souvent un symptôme de données sources défaillantes.

Cette réalité technique a une conséquence architecturale majeure. Intégrer l'IA dans un SI suppose au préalable d'avoir résolu des problèmes que beaucoup d'organisations reportaient depuis des années comme la gouvernance des données, le catalogage, la traçabilité, la qualité ou les cycles de vie. L'IA ne crée pas ces fondations, elle les exige.

L'écart entre adoption et industrialisation : ce que les chiffres disent vraiment

Le rapport McKinsey The State of AI in 2025 — novembre 2025, enquête auprès de 1 993 organisations dans 105 pays — documente un paradoxe qui n'en est plus un pour les architectes : 88 % des entreprises déclarent utiliser l'IA dans au moins une fonction métier, contre 78 % un an plus tôt. Mais seul un tiers d'entre elles a commencé à déployer l'IA à l'échelle de l'entreprise. Les deux tiers restants en sont encore à l'expérimentation ou au pilote. Et parmi les organisations qui mesurent un impact financier réel, seules 6 % qualifient cet impact de significatif au niveau de l'EBIT.

En France, l'INSEE publiait en juillet 2025 des chiffres encore plus sobres : 10 % des entreprises françaises de dix salariés ou plus déclaraient utiliser au moins une technologie d'IA en 2024, contre 6 % en 2023. Ce taux reste en retrait par rapport à la moyenne européenne de 13 %. Le secteur de l'information et de la communication dépasse 42 %, mais les entreprises de taille intermédiaire dans l'industrie ou les services restent largement à la marge. L'écart n'est pas un écart d'ambition, il est structurel.

Le bilan établi début 2026 par IT Social confirme que l'industrialisation progresse par paliers : environ un tiers seulement des cas d'usage IA déployés en entreprise ont atteint un véritable stade de production en 2025, avec des processus stabilisés et une intégration durable dans le système d'information. Ce taux a doublé par rapport à 2024, mais il reste minoritaire. La formule qui revient le plus fréquemment sur le terrain résume bien la situation : « il n'a jamais été aussi simple de faire un POC… et jamais aussi difficile de l'industrialiser. »

Pourquoi l'architecture d'entreprise devient-elle incontournable dès que l'on parle d'IA à l'échelle ?

L'architecture d'entreprise est le seul cadre qui relie stratégie, processus métiers, données et système d'information dans une vision cohérente. C'est ce que souligne Daniel, architecte d'entreprise en mission pour un grand acteur du retail français (Projexion, 2025) : « 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. »

Le problème, c'est que l'architecte d'entreprise arrive encore trop tard dans la plupart des organisations. Les initiatives IA naissent souvent dans les métiers, portées par un directeur commercial convaincu ou une équipe RH enthousiaste. Quand l'architecte est sollicité, les usages sont déjà définis, certaines briques techniques sont choisies, parfois contractuellement engagées. Son rôle devient alors essentiellement correctif : remettre de la cohérence entre des initiatives éparpillées, contenir la dette technique déjà générée, reconnecter l'ensemble à la trajectoire du SI.

Ce décalage temporel n'est pas un problème de gouvernance symbolique. Il a un coût réel. L'IA percute simultanément le juridique, la conformité, la sécurité, les données et les métiers. L'architecte d'entreprise est le médiateur naturel de ces tensions. Mais pour arbitrer, encore faut-il être dans la pièce quand les décisions se prennent.

L'IA agentique : une rupture supplémentaire pour les systèmes d'information

Si l'IA générative a dominé 2024, 2025 a vu émerger l'IA agentique. Eva Jaidan, directrice de l'intelligence artificielle chez MEGA (Bizzdesign), le formule clairement dans l'Enterprise Architecture Professional Journal : « Les agents IA intègrent raisonnement, planification et exécution, améliorés par la RAG (Retrieval-Augmented Generation) pour accéder à des informations contextualisées et actualisées. Ils peuvent exploiter des API, des moteurs de recherche et des bases de données pour exécuter des tâches complexes en temps réel. »

Les premières plateformes agentiques sont déjà en production : Salesforce Agentforce pour le service client et les ventes, HubSpot Agent.AI pour la coordination marketing et opérationnelle, Google Gemini Enterprise pour le traitement de données non structurées. Selon Gartner, environ 40 % des applications d'entreprise incluront des agents IA spécialisés à fin 2026, contre moins de 5 % aujourd'hui. Cette projection, rapportée par Intelance (décembre 2025), signale un changement de nature, pas de degré.

Un agent IA n'est pas un chatbot sophistiqué. C'est un système qui prend des décisions, déclenche des actions et modifie des états dans d'autres systèmes. Quand un agent IA écrit dans un ERP, approuve une commande ou alerte un responsable sur une anomalie de trésorerie, il devient un acteur du système d'information à part entière. Sa gouvernance — accès aux données, rôles, audit trail, mécanismes de rollback — doit être conçue architecturalement, avec les mêmes exigences qu'un composant logiciel critique. L'intégration sans gouvernance solide des données, sans role-based access control, sans traçabilité des décisions, génère des risques de fiabilité, de sécurité et de conformité qui n'ont rien d'hypothétique.

L'IA aggrave-t-elle la dette technique des systèmes d'information ?

La réponse courte est : oui, si les fondations sont fragiles. Une étude HFS Research (septembre 2025, 123 grandes entreprises Global 2000) le dit sans détour : 43 % des organisations interrogées estiment que l'IA génère déjà de nouvelles formes de dette technique. Les causes identifiées restent structurelles : mauvaise qualité du code citée par 83 % des répondants, pénuries de compétences par 80 %, prolifération du code sur mesure par 76 %. Phil Fersht, CEO de HFS Research, résume le problème : « L'IA accélérera la dette technique dans les architectures fragiles et lourdes en code. »

L'un des mécanismes les plus sous-estimés est ce que Gartner appelle le shadow AI. Des dizaines de projets pilotes IA non coordonnés lancés dans différentes directions métiers peuvent gonfler la dette technique autant que des systèmes legacy vieux de plusieurs décennies, précise un directeur technique cité dans Le Monde Informatique (décembre 2025). D'ici 2030, Gartner estime que 50 % des entreprises seront confrontées à des retards de déploiement IA ou à des coûts de maintenance élevés à cause de projets abandonnés, et que 40 % connaîtront des incidents de sécurité ou de conformité liés à une IA parallèle non autorisée.

Le paradoxe documenté par HFS Research est que 93 % des répondants reconnaissent néanmoins que l'IA pourrait devenir un catalyseur de modernisation en automatisant la documentation, l'analyse et la conversion du code hérité (un levier susceptible de réduire de 30 % les coûts et délais de migration). L'IA peut aider à résorber la dette, mais seulement si elle est elle-même gouvernée, auditée, intégrée dans une démarche architecturale explicite. Autrement dit : l'IA ne soigne pas la dette technique spontanément, elle peut en créer une nouvelle couche par-dessus l'ancienne.

Ce qu'une architecture SI doit intégrer pour accueillir l'IA sans se fracturer

Faire entrer l'IA dans le système d'information de façon durable suppose de traiter plusieurs couches simultanément. La couche données d'abord, qui est le prérequis absolu : catalogage, classification, traçabilité des flux, politique de qualité, cycles de vie. Sans cette fondation, ni RAG, ni fine-tuning, ni pipeline MLOps ne fonctionnent correctement. L'approche data mesh — décentralisation de la propriété des données par domaine métier tout en maintenant la cohérence d'ensemble — est citée par plusieurs études comme un levier efficace pour réduire le délai de mise à disposition des données pour les projets IA.

La couche plateforme ensuite : data lake pour les données non structurées, data warehouse pour les données structurées, outils d'orchestration comme Apache Kafka ou Airflow pour les flux, frameworks MLOps comme Dataiku ou MLflow pour le cycle de vie des modèles, et désormais LLMOps pour les modèles de langage — versioning des prompts, monitoring de la dérive, déploiement sécurisé, observabilité. Ces composants ne s'improvisent pas. Leur intégration dans le SI existant est un projet d'architecture à part entière, qui engage des choix de couplage, de sécurité et de souveraineté sur les données.

La couche gouvernance enfin, qui ne se réduit pas à la conformité réglementaire. Il s'agit de définir quelles décisions peuvent être automatisées, lesquelles requièrent une supervision humaine, et lesquelles ne doivent pas être déléguées à un modèle. Intelance (2025) pose la question directement : l'architecture d'entreprise doit concevoir ces garde-fous et ces workflows avant que les fournisseurs les imposent. La gouvernance de l'IA est une question d'architecture, pas de jurisprudence.

RGPD et AI Act : quand la conformité réglementaire redevient une contrainte architecturale

Le Règlement européen sur l'intelligence artificielle (Règlement UE 2024/1689, dit AI Act), adopté par le Parlement européen le 13 mars 2024 et publié au Journal officiel le 12 juillet 2024, est entré en vigueur le 1er août 2024. Son application est progressive : les interdictions de pratiques à risque inacceptable (scoring social, manipulation subliminale) sont applicables depuis le 2 février 2025 ; les obligations pour les modèles d'IA à usage général (GPAI) depuis août 2025 ; les systèmes à haut risque le seront à partir d'août 2026. L'échéance d'août 2026 est la plus critique pour la majorité des entreprises.

L'AI Act et le RGPD s'appliquent simultanément et de façon cumulative dès qu'un système IA traite des données personnelles — ce qui est le cas de la quasi-totalité des déploiements en entreprise. Un outil de scoring RH, un assistant client automatisé ou un moteur de détection de fraude relèvent des deux réglementations en même temps. Cela signifie concrètement qu'un système conforme à l'AI Act peut parfaitement être en infraction avec le RGPD, et inversement. La double conformité doit être établie de façon indépendante mais coordonnée.

Pour les architectes d'entreprise, cela se traduit par des exigences architecturales nouvelles : documentation technique des systèmes IA à haut risque (architecture, données d'entraînement, métriques, limites), traçabilité des flux de données personnelles, mécanismes de supervision humaine sur les décisions critiques, journaux d'audit accessibles aux autorités de contrôle. La CNIL a publié en 2025 des recommandations précisant que les principes de privacy by design s'appliquent aux modèles IA : les bases d'entraînement, les données mémorisées par les modèles et les prompts utilisateurs entrent dans le périmètre de protection. Ces contraintes ne s'ajoutent pas à l'architecture : elles doivent en faire partie dès la conception.

Du point de vue de la souveraineté numérique, la question des données personnelles dans les LLM hébergés hors UE reste entière. Le transfert vers des prestataires américains sans gouvernance solide des clés de chiffrement reste soumis au chapitre V du RGPD même avec des garanties contractuelles. Pour les organisations sensibles — secteur public, santé, finance, infrastructures critiques — le recours à des modèles open source déployés on-premise ou sur des clouds souverains certifiés devient une option architecturale sérieuse, non plus une posture idéologique.

Conclusion

L'engouement pour l'IA en entreprise n'était pas irrationnel. Les capacités des LLM sont réelles, les cas d'usage prometteurs nombreux, et les premiers retours sur investissement mesurables là où les fondations techniques étaient en place. Mais l'idée qu'il suffirait de brancher un modèle sur le SI existant pour en tirer de la valeur s'est heurtée à vingt ans de dette architecturale accumulée — données silotées, systèmes legacy mal documentés, gouvernance absente.

Ce que 2025 a confirmé, c'est que l'IA ne dispense pas de faire le travail d'architecture. Elle l'exige avec une acuité nouvelle. Un système d'information qui n'a pas résolu ses problèmes de qualité des données, de traçabilité et de gouvernance ne tirera pas grand-chose de l'IA — et risque de faire empirer la situation en ajoutant une couche de complexité supplémentaire. L'architecte d'entreprise, longtemps perçu comme un acteur de la planification et de la documentation, devient dans ce contexte un acteur de la robustesse et de la cohérence. Sa valeur n'est pas de dessiner des boîtes et des flèches, mais de garantir que les initiatives IA ne fracturent pas le SI en le transformant.

La question n'est plus de savoir si les entreprises vont adopter l'IA, mais de savoir lesquelles sauront la rendre durablement exploitable — et à quel coût architectural, humain et réglementaire.