Une première application d’IA peut être lancée en quelques jours. La deuxième réutilise rarement tout ce qui a été construit. La cinquième révèle les doublons : cinq systèmes d’authentification, trois bases vectorielles, des prompts copiés dans le code, aucun inventaire des données envoyées et des factures impossibles à relier à un usage.
Ce n’est pas un problème de modèle. C’est un problème de plateforme.
Le rôle d’une plateforme IA d’entreprise consiste à rendre les capacités communes accessibles sans imposer une technologie unique. Elle accélère les équipes produit, tout en donnant aux responsables sécurité, data, finance et conformité un point de contrôle cohérent. Son architecture doit accepter une réalité : les modèles changent plus vite que les processus métier.
1. Les chiffres qui changent la décision d’architecture
Le marché progresse à un rythme inhabituel. Selon l’AI Index 2026 de Stanford, 88 % des organisations interrogées déclaraient utiliser l’IA dans au moins une fonction en 2025, et 70 % utilisaient l’IA générative. Pourtant, l’usage des agents restait à un chiffre. L’écart entre expérimentation et autonomie opérationnelle rappelle qu’un chatbot réussi ne prouve pas qu’une entreprise sait exploiter une chaîne agentique.
La dépendance industrielle est forte. Plus de 90 % des modèles notables de 2025 provenaient de l’industrie. Les États-Unis comptaient 5 427 centres de données, plus de dix fois le nombre recensé dans n’importe quel autre pays selon le même rapport. La localisation d’un fournisseur, l’origine de son modèle et le lieu réel de calcul ne se déduisent donc pas d’un logo européen ou d’une interface commerciale.
Les performances et les prix bougent également. L’AI Index 2025 mesurait une baisse supérieure à 280 fois du coût d’inférence pour un niveau de performance comparable à GPT‑3.5 entre novembre 2022 et octobre 2024. MLCommons a ensuite observé, lors de MLPerf Inference v5.1, des gains allant jusqu’à 50 % pour les meilleurs systèmes par rapport à la version publiée six mois plus tôt. Un socle trop couplé à un fournisseur transforme cette amélioration du marché en coût de migration.
La qualité ne progresse pas de façon uniforme. Le chapitre Technical Performance de l’AI Index 2026 indique que les meilleurs agents sont passés d’environ 12 % à 66 % sur OSWorld, un benchmark d’utilisation d’ordinateur. C’est un bond majeur. C’est aussi un résultat qui laisse environ un cas sur trois non résolu dans ce cadre de test. Il serait imprudent de traduire 66 % sur un benchmark en 66 % de processus métier automatisables.
Enfin, les incidents augmentent. Stanford comptait 362 incidents liés à l’IA en 2025, contre 233 en 2024. L’architecture doit donc optimiser autre chose que la vitesse de mise en ligne : elle réduit le rayon d’impact lorsqu’un composant se trompe ou est attaqué.
2. Le parcours d’une requête, en onze contrôles
L’architecture devient plus lisible lorsqu’on suit une requête réelle. Prenons un chargé d’affaires qui demande : « Compare ce contrat à notre politique et prépare les points à négocier. »
2.1. Identité et contexte
La passerelle d’identité authentifie l’utilisateur et récupère son organisation, son rôle, son pays et le dossier concerné. L’identité ne sert pas seulement à ouvrir l’application. Elle détermine les documents accessibles, les outils autorisés et le niveau de journalisation.
Un compte de démonstration ne doit jamais disposer des mêmes connecteurs qu’un juriste. Une clé API partagée entre plusieurs applications rend cette séparation presque impossible.
2.2. Classification de la demande
Un routeur identifie le cas d’usage, la sensibilité, la langue, la complexité et la présence éventuelle de données personnelles. Cette étape peut combiner règles et petit modèle. Elle décide si la requête est autorisée, si elle exige une confirmation et quel budget peut être consommé.
Une demande de reformulation interne est peu risquée. Une recommandation contractuelle engage davantage. Le chemin ne doit pas être identique.
2.3. Protection des entrées
Le système analyse les pièces jointes, détecte les formats inattendus, retire les secrets évidents et limite la taille. Les documents récupérés sont traités comme des contenus non fiables. Une phrase cachée dans un PDF peut tenter de détourner les instructions du système.
La défense ne consiste pas à « demander au modèle d’être prudent ». Elle sépare les instructions, les données et les permissions. Les contenus n’obtiennent aucun droit par leur seule présence dans le contexte.
2.4. Accès aux données
La couche de recherche applique les autorisations avant de récupérer le contenu. Elle combine recherche lexicale, sémantique, filtres de métadonnées et reranking selon le besoin. Chaque extrait conserve sa source, sa version et sa date d’effet.
Une base vectorielle sans gestion des droits crée une fuite horizontale : l’utilisateur peut recevoir un passage qu’il ne pouvait pas ouvrir dans le système d’origine. Les permissions doivent suivre le document jusque dans le résultat.
2.5. Sélection du modèle
Le routeur choisit un modèle selon quatre contraintes : capacité, sensibilité, latence et coût. Un petit modèle peut extraire les clauses. Un modèle plus puissant peut comparer leurs effets. Un modèle hébergé dans un environnement dédié peut être exigé pour les données les plus sensibles.
La sélection n’est pas définitive. Le catalogue conserve une interface commune et un registre de capacités. Une nouvelle version passe d’abord sur du trafic fantôme, puis reçoit progressivement des requêtes.
2.6. Construction du contexte
Le système assemble la consigne, les extraits, le schéma de sortie, l’historique utile et les outils. Il supprime le contexte décoratif. Plus de tokens ne signifient pas automatiquement plus de qualité ; des passages contradictoires peuvent perturber la réponse et augmenter le coût.
Chaque template de prompt porte un identifiant et une version. Une modification est une mise en production, pas une retouche invisible dans une console.
2.7. Exécution des outils
Si le modèle doit consulter un CRM, calculer un montant ou créer une tâche, il propose un appel structuré. Une couche de politique vérifie l’outil, les paramètres et l’autorisation. Les actions à impact élevé exigent une validation humaine.
Lire n’est pas écrire. Préparer n’est pas envoyer. La politique d’exécution encode ces différences.
2.8. Validation de la sortie
Le résultat est contrôlé avant affichage : schéma valide, citations existantes, montants cohérents, absence de secret, niveau de confiance suffisant. Certaines vérifications sont déterministes. D’autres utilisent un second modèle, sans supposer que ce juge automatique est infaillible.
Lorsque les preuves sont insuffisantes, l’abstention est une sortie utile. Elle vaut mieux qu’une réponse élégante inventée.
2.9. Présentation et action humaine
L’interface montre les sources, les incertitudes et les actions proposées. Elle facilite la correction. Un bouton « utile / inutile » sans motif produit peu d’apprentissage ; une correction structurée alimente un futur jeu d’évaluation.
Le chargé d’affaires garde la décision. Si le système envoie directement au client, le niveau d’exigence change et le contrôle doit être repensé.
2.10. Journalisation
La couche de traces enregistre les éléments nécessaires : version du modèle, prompt, sources, outils, latence, coût, décision de l’utilisateur et éventuelle erreur. Les données sensibles sont minimisées, masquées ou séparées. Journaliser tout sans politique de conservation crée un nouveau risque.
2.11. Évaluation différée
Un échantillon rejoint une file de revue. Les erreurs sont classées : récupération, raisonnement, outil, politique, interface ou donnée source. Cette taxonomie transforme les incidents en travaux précis. Sans elle, l’équipe change le prompt au hasard.
3. L’architecture de référence en huit plans
Le parcours précédent se traduit par huit plans indépendants mais connectés.
| Plan | Responsabilité | Décision critique |
|---|---|---|
| Expérience | interfaces, assistants, API | où l’humain intervient |
| Orchestration | prompts, workflows, agents | degré d’autonomie |
| Modèles | catalogue, routage, fallback | capacité contre coût |
| Données | ingestion, recherche, droits | source de vérité |
| Outils | connecteurs, exécution, sandbox | permissions d’écriture |
| Contrôles | politiques, sécurité, conformité | refus et escalade |
| Observabilité | traces, évaluations, incidents | signal exploitable |
| FinOps | quotas, budgets, allocation | coût par résultat |
Cette séparation ne signifie pas huit produits. Elle évite qu’une application embarque tout dans un bloc impossible à auditer. Une petite organisation peut déployer le socle avec quelques services, à condition de conserver les frontières logiques.
4. Multi-modèles : éviter deux excès
Le premier excès consiste à dépendre entièrement d’un fournisseur. C’est simple au départ. Le coût, les limites et la politique du fournisseur deviennent ensuite des contraintes produit.
Le second consiste à intégrer dix modèles « pour rester agnostique ». L’équipe multiplie alors les tests, contrats, SDK et comportements à maintenir. L’agnosticisme total peut coûter plus cher que la dépendance qu’il cherche à éviter.
Une stratégie raisonnable définit trois voies : un modèle principal, une solution de repli et un modèle spécialisé lorsque la preuve économique existe. Les interfaces communes couvrent les fonctions de base. Les capacités propres à chaque fournisseur restent encapsulées, avec un test de sortie.
Le routage s’appuie sur des règles explicites. Il peut considérer :
- la classe de données ;
- la complexité estimée ;
- la longueur du contexte ;
- le temps de réponse maximal ;
- le coût autorisé ;
- la disponibilité du fournisseur ;
- la région de traitement ;
- le score obtenu sur le cas d’usage.
Le fallback ne doit pas dégrader silencieusement la sécurité. Si le modèle européen dédié est indisponible, basculer vers une API publique n’est pas une continuité de service acceptable. Le système peut plutôt suspendre le traitement et informer l’utilisateur.
5. Observabilité : voir une décision, pas seulement une requête
Les outils classiques surveillent le taux d’erreur, la latence et le CPU. Ils restent nécessaires. Le dispositif IA ajoute une observabilité sémantique.
Chaque trace relie la demande à ses sources, au modèle, aux outils, au résultat et à l’action finale. Elle permet de répondre à cinq questions : qu’a reçu le système, pourquoi a-t-il choisi ce chemin, quelles preuves a-t-il utilisées, qu’a-t-il produit, et qu’a fait l’utilisateur ?
Les indicateurs se répartissent en quatre groupes.
Service. Disponibilité, latence p50/p95/p99, erreurs, files d’attente et taux de fallback.
Qualité. exactitude par scénario, couverture des citations, taux d’abstention, violations de format, corrections humaines et régressions.
Risque. tentatives d’injection, appels d’outils refusés, données sensibles détectées, accès anormaux et incidents confirmés.
Valeur. temps gagné, délai de cycle, volume traité sans reprise, adoption et résultat métier.
Une moyenne globale masque les échecs rares. On segmente par langue, client, type de document, version de modèle et criticité. Une régression de 2 points sur l’ensemble peut cacher une chute de 20 points sur les contrats allemands.
6. SLO, budget d’erreur et déploiement
Un objectif de niveau de service, ou SLO, décrit ce que l’application doit tenir. Exemple : 99,5 % des demandes autorisées reçoivent une réponse en moins de quinze secondes ; 98 % des citations pointent vers un passage accessible ; aucune action financière n’est exécutée sans confirmation.
Le budget d’erreur quantifie la marge tolérée. S’il est consommé, l’équipe ralentit les nouvelles fonctionnalités et corrige la fiabilité. Pour la qualité sémantique, le budget peut porter sur les erreurs critiques observées dans un échantillon contrôlé.
Les versions suivent un chemin progressif : tests hors ligne, red team, trafic fantôme, groupe interne, faible pourcentage de production, puis généralisation. Le rollback inclut le modèle, le prompt, la recherche et les règles. Revenir seulement au modèle précédent ne suffit pas si l’index documentaire a changé.
7. FinOps IA : un grand livre des coûts
La facture doit être attribuable à un produit, une équipe, un client et un résultat. Le grand livre enregistre pour chaque transaction : tokens d’entrée et de sortie, appels de recherche, stockage, temps GPU, outils externes, retries et revue humaine.
Trois ratios sont particulièrement utiles.
Coût par tâche terminée. Il inclut les reprises et les échecs, pas seulement l’appel réussi.
Coût par unité de valeur. Par exemple, coût par dossier qualifié ou par heure nette économisée. Ce ratio permet de comparer l’IA à une amélioration de processus classique.
Coût marginal de qualité. Combien coûte le passage de 90 à 94 % sur les cas importants ? Le meilleur modèle peut multiplier la facture pour un gain sans effet métier.
Les leviers sont ensuite ciblés : cache pour les contenus stables, résumé du contexte, batch, modèle plus petit, limite de retries, index plus précis ou suppression d’une étape de jugement automatique. La réduction doit être testée sur la qualité. Une économie de tokens qui augmente les corrections est une fausse économie.
8. Sécurité : limiter le rayon d’action
Centraliser crée un point de contrôle, mais aussi une cible. Le moindre privilège s’applique à chaque connecteur. Les secrets sont courts, rotatifs et attachés à un service. Les environnements de test n’accèdent pas aux données de production.
Les agents exigent une attention supplémentaire. Le NIST a montré, dans une évaluation publiée en 2025, que le taux de réussite d’attaques de détournement d’agents passait de 57 % avec une tentative à 80 % après 25 tentatives dans le protocole étudié. Bloquer une formulation malveillante ne suffit donc pas. Les permissions, confirmations, plafonds et environnements isolés doivent contenir une réussite éventuelle.
Les contenus externes sont non fiables. Les sorties le sont aussi. Avant d’être interprétée par un navigateur, une base ou un shell, chaque sortie passe par une validation stricte. Un modèle n’écrit jamais directement une requête libre dans un système critique.
9. Souveraineté et résidence : poser les bonnes questions
La résidence décrit où une donnée est stockée ou traitée. La souveraineté décrit qui peut décider, accéder, modifier, interrompre ou remplacer. Les deux se recouvrent sans être équivalentes.
Une analyse utile cartographie : la société contractante, le lieu d’hébergement, les sous-traitants, le droit applicable, l’origine des composants, les clés de chiffrement, l’administration, la télémétrie et la capacité d’export. Elle distingue les données au repos, en transit et présentes dans la mémoire d’exécution.
L’hébergement souverain sans compétences internes peut rester fragile. Une architecture ouverte sans exercice de restauration peut rester captive. La maîtrise se prouve concrètement : changer de modèle, couper un fournisseur, restaurer un index et révoquer un connecteur.
10. Construire ou acheter ?
Acheter un socle intégré accélère l’authentification, le catalogue et l’observabilité. Construire offre davantage de contrôle et d’adaptation. Le bon choix dépend du différenciateur.
On achète plus volontiers les capacités génériques : passerelle de modèles, gestion de secrets, stockage, traces et tableaux de bord. On construit davantage la logique métier : taxonomie, règles de décision, évaluations, expérience utilisateur et connecteurs spécifiques.
Le contrat doit protéger les actifs. Les prompts, tests, annotations, traces utiles et configurations doivent être exportables. Une solution qui permet d’entrer facilement mais pas de repartir transfère le risque vers l’avenir.
11. Feuille de route de déploiement
Phase 1 — Inventorier. Recenser les cas d’usage, modèles, données, propriétaires, contrats et coûts existants. Éliminer les clés partagées et les prototypes sans responsable.
Phase 2 — Standardiser le minimum. Mettre en place identité, passerelle, journalisation, registre de prompts et règles de données. Un seul cas pilote traverse le parcours complet.
Phase 3 — Mesurer. Construire les jeux d’évaluation, les SLO et l’allocation des coûts. Comparer deux modèles sur les mêmes tâches.
Phase 4 — Industrialiser. Ajouter routage, fallback, déploiement progressif, alertes et revues d’incident. Ouvrir le socle à plusieurs équipes avec des templates.
Phase 5 — Exercer la réversibilité. Couper volontairement un fournisseur dans un environnement contrôlé. Restaurer les données. Mesurer le temps réel de migration.
Le socle n’est terminé à aucune de ces étapes. Il évolue comme un produit interne, avec des utilisateurs, une feuille de route, un responsable et un niveau de service.
12. Le jour où le fournisseur devient indisponible
Coupez le chemin principal. Que reste-t-il ? L’utilisateur doit le savoir. L’équipe aussi.
Le scénario de continuité documente la détection, le refus des nouvelles actions, la file des demandes en attente, la reprise manuelle, la communication et la restauration. Les données déjà confiées au service sont distinguées des appels qui n’ont jamais abouti. Un incident d’une heure et un retrait définitif ne réclament pas le même plan, mais tous deux exigent un propriétaire, un journal, un message compréhensible pour l’utilisateur, une règle pour les traitements partiellement exécutés, une procédure de réconciliation après reprise et un délai au-delà duquel le mode dégradé devient lui-même la nouvelle source de risque opérationnel.
L’exercice apporte une vérité rarement visible dans un diagramme : la réversibilité dépend des personnes, des contrats et des formats autant que du code. Elle se chronomètre. Elle se finance. Elle s’améliore. Un plan qui n’a jamais été joué reste une hypothèse élégante. Au moment de conclure, le procès-verbal doit indiquer précisément quelles fonctions ont survécu, quelles données ont été récupérées, quelles opérations ont demandé une intervention, quels engagements contractuels se sont révélés utiles, quelles compétences manquaient et combien de temps supplémentaire serait nécessaire pour transformer ce simple exercice contrôlé en une migration complète qui préserverait les droits, l’historique, les évaluations et la continuité du métier.
13. Questions fréquentes
13.1. Faut-il une plateforme avant le premier projet IA ?
Non. Il faut toutefois éviter que le pilote contourne identité, sécurité et mesure. Le premier cas peut construire le socle minimal ; ses composants sont ensuite généralisés lorsqu’un second besoin confirme leur utilité.
13.2. Une passerelle multi-modèles suffit-elle ?
Non. Elle centralise l’accès et parfois les coûts. Elle ne résout ni les droits documentaires, ni l’évaluation, ni les appels d’outils, ni le contrôle humain.
13.3. Que faut-il journaliser ?
Ce qui permet de diagnostiquer, auditer et améliorer, avec une durée proportionnée. Les données personnelles et secrets doivent être minimisés ou masqués. Une trace exploitable possèd'un identifiant de bout en bout et les versions des composants.
13.4. Comment éviter l’explosion des coûts ?
Attribuer chaque dépense, fixer des budgets par tâche, limiter les retries et mesurer le coût des reprises. Ensuite seulement, optimiser le modèle ou le contexte. Sans métrique de valeur, la baisse de facture peut dégrader l’usage.
13.5. Peut-on mélanger cloud public et hébergement privé ?
Oui, si le routage dépend de la classe de données et si les chemins sont testés. L’architecture hybride ajoute toutefois des opérations, des évaluations et une gestion de versions. Elle doit répondre à un besoin vérifiable.
14. Ce que Logiks recommande
Concevez la plateforme autour du parcours d’une décision, pas autour du fournisseur du moment. Centralisez l’identité, les politiques, les traces, l’évaluation et les coûts. Laissez les modèles remplaçables. Puis limitez l’autonomie à ce que l’organisation sait observer, interrompre et restaurer.
15. Sources principales
- Stanford Institute for Human-Centered AI, AI Index Report 2026 : https://hai.stanford.edu/ai-index/2026-ai-index-report
- Stanford HAI, chapitre Economy : https://hai.stanford.edu/ai-index/2026-ai-index-report/economy
- Stanford HAI, chapitre Technical Performance : https://hai.stanford.edu/ai-index/2026-ai-index-report/technical-performance
- Stanford Institute for Human-Centered AI, AI Index Report 2025 : https://hai.stanford.edu/ai-index/2025-ai-index-report
- MLCommons, MLPerf Inference v5.0 Results : https://mlcommons.org/2025/04/mlperf-inference-v5-0-results/
- MLCommons, MLPerf Inference v5.1 Results : https://mlcommons.org/2025/09/mlperf-inference-v5-1-results/
- NIST, Strengthening AI Agent Hijacking Evaluations : https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations
- OWASP, Top 10 for Agentic Applications : https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/