IA, données et plateformes : passer du prototype à la production.

Ce qui sépare un démonstrateur d’un système en production

Un démonstrateur tourne sur un extrait de données préparé à la main, il est évalué par la personne qui l’a construit, et son coût d’exécution est nul à l’échelle où il fonctionne. Un système en production consomme des données dont la qualité varie sans prévenir, sert des utilisateurs qui ne pardonnent pas, se mesure sur des indicateurs métier, et coûte à chaque appel.

Quatre chantiers séparent l’un de l’autre, et aucun ne concerne le choix du modèle :

• La donnée. Origine, fraîcheur, droits d’usage, qualité mesurée. Un système entraîné ou alimenté par une donnée non gouvernée produit un résultat que personne ne peut défendre.
• La chaîne de livraison. Déployer un modèle n’est pas déployer une application. Versionnement des jeux de données, reproductibilité, retour arrière, tests.
• L’observabilité. Un modèle en production dérive. Sans mesure continue de ce qu’il produit, la dégradation se découvre par une réclamation client.
• Le cadre juridique. Documentation, transparence, traçabilité des décisions. Ce chantier n’était pas contraignant il y a deux ans, il l’est devenu.

C’est ce qui donne sa cohérence à un périmètre qui paraît hétérogène. Une expérimentation n’a besoin ni de plateforme de données, ni de pipeline de livraison, ni de stratégie de stockage. Un système en production a besoin des trois.

IA générative : ce que les entreprises déploient réellement

Définition. Un grand modèle de langage est un système entraîné sur de vastes corpus textuels, capable de produire du texte, du code ou des analyses à partir d’une instruction. Il ne consulte pas une base de connaissances : il génère une réponse probable, ce qui explique à la fois sa polyvalence et son besoin d’ancrage documentaire.

Trois familles d’usages se sont détachées, avec des profils de risque très différents.

Les assistants de productivité individuelle, intégrés à la bureautique et aux outils de développement. Déploiement rapide, bénéfice difficile à mesurer, principal enjeu de gouvernance : la fuite de données vers un service tiers et l’usage non déclaré. Notre section LLM et IA générative en entreprise traite le sujet en détail.

Les systèmes d’accès à la connaissance interne, où le modèle est ancré sur les documents de l’organisation. C’est la famille la plus déployée, et celle où la qualité du résultat dépend presque entièrement de la qualité du corpus et de la gestion des droits d’accès. Un système qui restitue à un collaborateur un document qu’il n’aurait pas dû voir constitue un incident de sécurité, pas un défaut de modèle.

Les agents autonomes, qui exécutent des actions et non plus seulement des réponses. C’est la frontière actuelle et la plus exigeante : elle suppose un contrôle des droits, une traçabilité des actions et un point d’arrêt humain. Voir notre section copilots et agents IA en production.

Sur la sélection des cas d’usage, un critère prime : la tolérance à l’erreur. Un processus où une réponse approximative est rattrapable se prête à l’expérimentation. Un processus où elle engage l’organisation demande un dispositif de contrôle qui coûte souvent plus cher que le gain attendu. Nos cas d’usage IA métier documentent les déploiements sectoriels.

AI Act : ce qui s’applique vraiment depuis août 2026

C’est le sujet sur lequel le récit dominant est faux, et où l’écart entre ce qui a été titré et ce qui est en vigueur expose les organisations.

Ce qui a été reporté, et ce qui ne l’a pas été

Le paquet dit Digital Omnibus, adopté à l’été 2026, a reporté l’application des obligations pesant sur les systèmes à haut risque : au 2 décembre 2027 pour les systèmes autonomes de l’annexe III, recrutement, notation de crédit, éducation, justice, biométrie, infrastructures critiques ; au 2 août 2028 pour les systèmes intégrés à des produits déjà réglementés relevant de l’annexe I.

Les obligations de transparence de l’article 50 n’ont pas été reportées. Elles s’appliquent depuis le 2 août 2026, comme prévu au calendrier initial, en même temps que l’application générale du règlement et les pouvoirs de sanction sur les fournisseurs de modèles à usage général.

Concrètement, une organisation doit informer l’utilisateur lorsqu’il interagit avec un système d’intelligence artificielle, et signaler les contenus générés ou manipulés. Une échéance complémentaire au 2 décembre 2026 concerne le marquage lisible par machine des contenus produits par des systèmes génératifs déjà sur le marché avant août 2026.

Ce qu’un DSI doit en tirer

Le report ne libère pas de l’obligation de préparation. Il déplace une échéance sur un chantier, la qualification des systèmes à haut risque, dont la durée se compte en trimestres. Une organisation qui utilise un outil d’aide au tri de candidatures dispose de quinze mois pour documenter, qualifier et mettre en conformité un système qui relève de l’annexe III.

Le travail à engager maintenant est le même quelle que soit l’échéance : inventorier les systèmes d’IA en usage, y compris ceux souscrits hors DSI, et qualifier leur niveau de risque. Sans cet inventaire, aucune trajectoire de conformité n’est constructible. L’exercice révèle presque toujours plus de systèmes que prévu, l’IA étant désormais embarquée dans des outils métier souscrits sans passer par la direction informatique.

Le sujet est développé dans notre section gouvernance IA et AI Act, qui suit l’évolution du cadre et des lignes directrices.

En complément : le Digital Omnibus sur l’IA (règlement UE 2026/1744) a été adopté formellement par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026. Il est entré en vigueur le 27 juillet 2026.

La Commission européenne et le Bureau de l’IA (AI Office) ont publié des lignes directrices clés : définition d’un système d’IA (6 février 2025), code de bonnes pratiques pour les modèles d’IA à usage général (10 juillet 2025, jugé conforme le 1er août 2025), et un projet de lignes directrices sur l’article 50 (transparence) le 19 mai 2026, encore en consultation à cette date.

Le texte reporte les obligations « haut risque » : annexe III (systèmes autonomes) au 2 décembre 2027, annexe I (systèmes intégrés) au 2 août 2028, mais maintient l’application générale du Règlement IA au 2 août 2026, notamment l’article 50

Le socle de données

Aucun système d’IA ne dépasse la qualité de la donnée qui l’alimente. C’est un lieu commun, mais il a une traduction opérationnelle précise.

Les plateformes de données ont convergé. La distinction entre entrepôt et lac s’est estompée au profit d’architectures qui combinent le stockage à faible coût et la gouvernance transactionnelle. Le choix structurant n’est plus le format mais le modèle d’organisation : plateforme centralisée pilotée par une équipe unique, ou responsabilité distribuée aux domaines métier avec un socle commun. Le second modèle réduit le goulet d’étranglement et augmente l’exigence de gouvernance.

L’analytique reste le premier consommateur de ce socle, et le plus rentable. Une organisation qui ne sait pas produire un indicateur fiable ne saura pas produire un modèle fiable. Voir nos sections MLOps et plateformes de données et Big Data et analytics.

Les bases de données se sont spécialisées. Aux moteurs relationnels s’ajoutent les bases orientées documents, les bases temporelles, les bases orientées graphe et, portées par les usages d’IA, les bases vectorielles qui indexent des représentations sémantiques. La tentation d’ajouter un moteur par usage se paie en exploitation : chaque technologie supplémentaire ajoute une sauvegarde, une supervision, une compétence et une trajectoire de mise à jour. Notre section bases de données modernes traite ces arbitrages.

Stocker, protéger, conserver

Trois besoins distincts que les organisations confondent régulièrement, avec des conséquences budgétaires et réglementaires.

Le stockage de production sert les applications. Le choix entre stockage bloc, fichier et objet se fait sur le profil d’accès, pas sur le prix au téraoctet. Le stockage objet s’est imposé comme socle des plateformes de données et des usages d’IA, pour sa capacité à absorber de très gros volumes non structurés à coût maîtrisé. Voir notre section stockage objet, SAN et NAS.

La sauvegarde protège contre la perte et contre l’attaque. Elle relève d’une logique de restauration testée, et le sujet est traité dans notre couverture de la résilience face aux rançongiciels.

L’archivage répond à une obligation de conservation, avec des exigences d’intégrité, de lisibilité et parfois de valeur probante sur des durées qui dépassent celle des supports. Le point que les organisations découvrent tard : un format propriétaire non maintenu rend une archive illisible bien avant que le support ne se dégrade. Notre section archivage long terme traite ces contraintes.

La conséquence pour l’IA : les volumes générés par les usages d’IA, jeux d’entraînement, empreintes vectorielles, journaux d’inférence, croissent vite et sans politique de cycle de vie par défaut. C’est le poste de stockage qui dérape le plus souvent, faute d’avoir été anticipé.

Industrialiser : la chaîne de livraison

C’est le chantier que les projets d’IA découvrent au moment de passer en production, et qu’ils auraient dû traiter avant.

La chaîne d’intégration et de livraison en continu automatise la construction, les tests et le déploiement. Y intégrer la sécurité, analyse des dépendances, détection de secrets, contrôle des images, transforme une contrainte de fin de cycle en garde-fou permanent. Un modèle d’IA ajoute ses propres exigences : versionnement des jeux de données, reproductibilité de l’entraînement, capacité de retour arrière sur une version de modèle. Voir notre section CI/CD et DevSecOps.

L’infrastructure décrite comme du code rend l’environnement reproductible, auditable et versionné. C’est le prérequis d’une reconstruction rapide après incident, et la condition d’une gouvernance réelle sur ce qui est déployé. Notre section Infrastructure as Code détaille les pratiques et les pièges, à commencer par la gestion des secrets et la dérive entre l’état déclaré et l’état réel.

L’observabilité dépasse la supervision. Journaux, métriques et traces distribuées permettent de qualifier un incident sur une architecture répartie. Pour un système d’IA, elle prend une dimension supplémentaire : mesurer la dérive du modèle, le coût par appel, la latence, et la qualité des réponses produites. Une organisation qui ne mesure pas ces quatre dimensions ne pilote pas son système, elle l’observe fonctionner. Voir notre section observabilité et monitoring.

Low-code et no-code : le sujet de gouvernance

Les plateformes de développement visuel permettent à des profils métier de construire des applications sans écrire de code. Elles répondent à une demande réelle, et elles produisent une informatique parallèle que la DSI ne voit pas.

Les deux questions à trancher : qui est responsable d’une application construite par un métier quand elle tombe en production, et que se passe-t-il quand la personne qui l’a construite quitte l’organisation. La réponse ne consiste ni à interdire, ni à laisser faire, mais à définir un périmètre autorisé, un socle de sécurité et un point de bascule vers la DSI au-delà d’un seuil de criticité. Voir notre section low-code et no-code en B2B.

Les quatre arbitrages à instruire cette année

1. Inventorier les systèmes d’IA en usage et qualifier leur niveau de risque, y compris ceux embarqués dans des outils métier souscrits hors DSI. C’est le prérequis de toute trajectoire de conformité, et il ne dépend d’aucune échéance.

2. Décider du modèle d’organisation de la donnée : plateforme centralisée ou responsabilité distribuée aux domaines. Ce choix conditionne le rythme de livraison plus que la technologie retenue.

3. Traiter la chaîne de livraison avant le prochain cas d’usage, et non après. Un démonstrateur validé sans pipeline de déploiement reste un démonstrateur.

4. Définir une politique de cycle de vie sur les données générées par l’IA, avant que le poste de stockage ne devienne une ligne budgétaire subie.

Explorer les sujets du cluster

Intelligence artificielle

• LLM et IA générative en entreprise : usages déployés, ancrage documentaire, maîtrise des risques
• Copilots et agents IA : passage à l’action, droits, traçabilité
• Gouvernance IA et AI Act : calendrier, qualification des risques, conformité
• Cas d’usage métier : déploiements sectoriels et retours d’expérience

Données et plateformes

• MLOps et plateformes de données : industrialisation des modèles et socle technique
• Big Data et analytics : architectures, exploitation, indicateurs
• Bases de données modernes : relationnel, documents, graphe, vectoriel

Stockage et conservation

• Stockage objet, SAN et NAS : profils d’accès, volumétrie, coût
• Archivage long terme : intégrité, lisibilité, valeur probante

Ingénierie de plateforme

• CI/CD et DevSecOps : chaîne de livraison et sécurité intégrée
• Infrastructure as Code : reproductibilité, secrets, dérive de configuration
• Observabilité et monitoring : journaux, métriques, traces, dérive de modèle
• Low-code et no-code B2B : périmètre autorisé et gouvernance

Ressource iTPro+

Grille de qualification AI Act. Inventaire type des systèmes d’IA, arbre de décision pour qualifier un système au regard des annexes I et III, calendrier des échéances après le Digital Omnibus, et modèle de fiche de documentation par système. Document réservé aux abonnés iTPro+.