IA générative : du POC à la production, les choix structurants pour la DSI

Passer une IA générative du POC à la production revient à trancher cinq décisions : l’architecture en couches, le type de modèle, la méthode d’adaptation (RAG, fine-tuning ou agents), l’hébergement et le cadre règlementaire. L’implémentation d’IA générative se juge au coût par usage, à la tenue en charge et à la conformité, pas à une démonstration réussie. Toute stratégie IA générative de DSI gagne à hiérarchiser ces choix avant le moindre chantier de mise en production.

Pourquoi tant de POC n’aboutissent pas à une mise en production ?

Une preuve de concept réussit parce qu’elle contourne ce que la production impose : données propres, volumétrie réelle, exigences de sécurité, milliers d’utilisateurs. Gartner prévoyait en juillet 2024 qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept d’ici fin 2025, faute de qualité des données, de contrôle des risques, de maîtrise des coûts ou de valeur claire.

La suite a confirmé la tendance : selon une enquête S&P Global menée auprès de 1 006 responsables IT et métiers, la part des entreprises qui abandonnent la majorité de leurs initiatives d’IA est passée de 17 % en 2024 à 42 % en 2025. Le modèle est rarement en cause. Les décisions repoussées, elles, finissent toujours par coûter.

Les trois couches à décider : applicatif, middleware, infrastructure

Un projet d’IA générative se découpe en trois couches. La couche applicative regroupe interfaces, assistants métier et connexions aux outils existants (CRM, ERP, messagerie). Le middleware orchestre : appels aux modèles, bases de connaissances, journaux, garde-fous. L’infrastructure fournit calcul, stockage, réseau et inférence.

 

Mieux vaut décider du haut vers le bas, sans acheter de matériel avant de savoir ce que les métiers utiliseront. Le middleware mérite l’attention la plus soutenue : il isole l’application du modèle. Une DSI qui y loge ses règles de sécurité, sa traçabilité et ses jeux d’évaluation garde la liberté de changer de modèle sans réécrire les usages.

Modèle propriétaire ou open-weight : quel arbitrage ?

Un modèle propriétaire s’utilise le plus souvent par API, facturée à l’usage ; les poids restent chez le fournisseur. Un modèle open-weight met ses poids à disposition : l’entreprise peut l’héberger, l’adapter et l’auditer. Ce n’est pas de l’open source au sens strict, puisque données et code d’entraînement ne sont pas toujours publiés.

Le premier raccourcit le démarrage et allège l’exploitation. Le second donne la maîtrise des données et du lieu d’exécution, mais exige une équipe capable d’opérer l’inférence, de dimensionner les GPU et d’appliquer les correctifs. Un volume faible ou irrégulier plaide pour l’API ; une charge forte et stable, ou des données qui ne doivent pas sortir, rapproche de l’hébergement interne. Les deux se combinent.

RAG, fine-tuning ou agents : que choisir selon le cas d’usage ?

Le RAG (retrieval-augmented generation) interroge une base documentaire au moment de la question et fournit les passages trouvés au modèle. Il convient aux réponses qui dépendent de documents internes mouvants, comme procédures ou contrats, cite ses sources et se met à jour sans réentraînement.

Le fine-tuning modifie le comportement du modèle à partir d’exemples : format de sortie, ton, vocabulaire sectoriel, tâche étroite et répétitive. Il ne sert pas à injecter des faits qui vieillissent. Les agents IA vont plus loin : le modèle planifie des étapes et appelle des outils pour agir, par exemple créer un ticket. Permissions strictes et supervision humaine deviennent la règle.

Deux protocoles structurent l’interopérabilité. MCP (Model Context Protocol) standardise la connexion d’un modèle aux outils et aux données ; A2A (Agent2Agent) organise le dialogue entre agents. Tous deux relèvent désormais de la Linux Foundation, mais Gartner range l’interopérabilité des agents parmi les technologies les moins mûres de son Hype Cycle 2026. Mieux vaut les isoler derrière le middleware. Le même cabinet prévoit que plus de 40 % des projets d’IA agentique seront abandonnés d’ici fin 2027.

Déployer et passer à l’échelle : cloud, coûts, performance

Cloud public, cloud de confiance, hébergement sur site ou combinaison des trois : le choix découle de la sensibilité des données, de la volumétrie et des compétences disponibles. Le passage à l’échelle fait varier trois paramètres à la fois.

Le coût d’abord : entre une poignée de testeurs et tous les collaborateurs, le nombre de requêtes change d’ordre de grandeur, et la facture suit. La performance ensuite : latence, débit en période de pointe. La fiabilité enfin : version de modèle figée, bascule en cas de panne, évaluation continue de la qualité. Mesurer le coût par usage dès le pilote évite les mauvaises surprises.

Sécurité, confidentialité et AI Act : ce qu’il faut vérifier

Les risques propres à l’IA générative s’ajoutent à ceux du système d’information : injection de prompt, fuite de données par les réponses, accès excessif des agents aux outils. Parmi les parades : cloisonner les données du RAG selon les droits d’accès, filtrer entrées et sorties, journaliser les appels, accorder aux agents des droits minimaux. Côté confidentialité, le RGPD s’applique indépendamment de l’AI Act.

 

Sur l’AI Act, restons factuels. Les obligations des fournisseurs de modèles à usage général s’appliquent depuis le 2 août 2025, et la Commission européenne dispose de pouvoirs de contrôle et de sanction depuis le 2 août 2026. Une entreprise qui intègre un modèle tiers est généralement fournisseur ou déployeur d’un système d’IA, rarement fournisseur du modèle.

Le règlement (UE) 2026/1744, dit omnibus numérique, en vigueur depuis le 27 juillet 2026, a reporté les obligations « haut risque » de l’annexe III (recrutement, crédit, éducation) au 2 décembre 2027, et celles des systèmes intégrés à des produits règlementés au 2 août 2028. Seul ce chapitre bouge. Le niveau de risque suit l’usage, non le modèle : un assistant de rédaction relève du risque minimal, le même chargé de trier des candidatures bascule en haut risque.

Organiser l’équipe et les compétences

Une équipe d’IA générative en production réunit des data engineers pour les pipelines et les bases documentaires, des ML engineers pour l’évaluation et le déploiement des modèles, des architectes, des spécialistes sécurité et conformité, et des responsables métier qui portent le cas d’usage. Capgemini Institut propose sur ce terrain une formation IA générative en entreprise de deux jours (14 heures), qui parcourt les couches applicative, middleware et infrastructure, puis traite la constitution de l’équipe : profils, rôles, fidélisation des talents. Capgemini Institut conçoit des formations courtes de 1 à 3 jours pour cadres, managers, dirigeants, fonctions métiers et IT. Fort de plus de 45 ans d’expérience auprès des entreprises, l’organisme fait appel à des animateurs experts du terrain et détient la certification Qualiopi.

FAQ

Quelle différence entre un POC et une mise en production ?

Le POC vérifie qu’un cas d’usage est faisable sur un échantillon de données et pour un groupe restreint. La mise en production ajoute sécurité, supervision, exploitation, maîtrise des coûts et conformité.

RAG ou fine-tuning : lequel privilégier en premier ?

Pour les cas documentaires, le RAG, puisqu’il s’appuie sur des sources à jour et citables. Le fine-tuning vient ensuite, pour corriger un style, un format ou une tâche précise.

L’AI Act s’applique-t-il déjà à un projet d’IA générative ?

En partie. Les interdictions et les obligations visant les modèles à usage général sont en vigueur ; seules les obligations « haut risque » de l’annexe III sont reportées au 2 décembre 2027. Tout dépend du cas d’usage plus que de la technologie.