# IA générative, du POC à la production : déployer ce qui a fait ses preuves

> Une preuve de concept d'IA générative réussit presque toujours en démonstration. Le passage en production échoue sur autre chose : des données réelles, des droits, des coûts, une exploitation. Ce guide décrit comment cadrer le test pour qu'il réponde à ces questions, et comment déployer ensuite.

Source : https://smartagt.ai/fr/ressources/poc-ia-production/
Publié le : 2026-09-22
Éditeur : SmartAGT (NERVIAL LABS)

---
## Pourquoi tant de POC ne passent pas en production {#echec}

Un POC d'IA générative montre qu'un modèle sait faire une tâche. La production exige qu'il la fasse sur tous les cas réels, pour tous les utilisateurs concernés, avec leurs droits, pour un coût connu, et qu'une équipe sache l'exploiter. L'écart entre les deux explique la plupart des arrêts.

Les causes reviennent d'un projet à l'autre :

- **Le cas d'usage a été choisi pour impressionner**, pas pour être mesuré. Une démonstration spectaculaire sur un sujet marginal ne justifie aucun budget de déploiement.
- **Les données étaient celles de la démonstration** : un jeu de documents propres, choisis, sans les versions obsolètes, les doublons et les formats improbables de la base réelle.
- **Personne ne possède le résultat.** L'équipe technique a livré, le métier a apprécié, mais aucun responsable ne porte la décision de mise en production ni le service ensuite.
- **Les couches invisibles manquaient** : identité, droits sur les documents, traces, plafonds de dépense, supervision. Absentes du POC, elles transforment le passage en production en second projet, plus long que le premier.

La conséquence pratique : un POC utile est conçu dès le départ pour répondre aux questions de la production, pas seulement à la question « est-ce que le modèle sait faire ».

## Cadrer le POC pour qu'il puisse passer {#cadrer}

Le cadrage se décide avant la première ligne de configuration. Il tient en quatre choix.

- **Un cas d'usage fréquent et borné** Une tâche répétée souvent, par une population identifiée, sur un périmètre documentaire délimité. La fréquence fait la valeur, le périmètre rend la mesure possible.
- **Des données réelles** Les documents et les dossiers tels qu'ils existent, avec leurs défauts, et les droits d'accès réels. Un POC sur données nettoyées mesure un cas qui n'existera pas.
- **L'environnement cible** Les modèles, l'hébergement et les intégrations prévus pour la production. Changer de modèle ou d'architecture après le POC invalide une partie de ses résultats.
- **Un responsable métier** Une personne qui attend le résultat, participe à l'évaluation et portera la décision de mise en production.

*Quatre choix de cadrage qui décident de la suite, pris avant de commencer.*

Le cas d'usage idéal pour un premier POC n'est ni le plus ambitieux ni le plus visible : c'est celui dont la valeur se mesure simplement. Répondre aux questions récurrentes d'un service à partir de sa documentation, préparer un premier niveau de réponse à des demandes entrantes, synthétiser des dossiers avant une décision. Le guide sur le [RAG en entreprise](~/ressources/rag-entreprise/) détaille ce qui fait la qualité d'un assistant documentaire, le cas le plus fréquent.

## Fixer les critères de sortie avant de commencer {#criteres}

Un POC sans critère de sortie écrit à l'avance se conclut toujours par « c'est prometteur ». Les critères se fixent avec le responsable métier, et les seuils se décident avant de voir les résultats.

| Critère | Comment le mesurer | Ce qu'il faut décider avant |
| --- | --- | --- |
| Qualité des réponses | Évaluation par des experts métier sur un échantillon représentatif, cas limites compris | Le taux de réponses acceptables exigé, et ce qu'est une erreur grave |
| Gain pour les utilisateurs | Temps passé sur la tâche avant et pendant le POC, sur les mêmes personnes | Le gain minimal qui justifie le déploiement |
| Adoption | Utilisateurs actifs parmi les testeurs, au fil des semaines | Le niveau d'usage attendu sans relance |
| Coût par tâche | Consommation réelle rapportée au nombre de tâches traitées | Le coût maximal acceptable à l'échelle |
| Sécurité et conformité | Respect des droits d'accès, traces disponibles, avis du RSSI et du DPO | Les conditions bloquantes |

L'échantillon d'évaluation est le point le plus souvent négligé. Il doit être construit avant le test, à partir de cas réels, et inclure les demandes difficiles : ambiguës, hors périmètre, portant sur des documents contradictoires. Un modèle jugé sur dix exemples choisis ne dit rien de son comportement sur le reste.

## Ce qui change entre le POC et la production {#changements}

Le passage en production ne consiste pas à ouvrir le POC à plus de monde. Plusieurs dimensions changent de nature.

| Dimension | Pendant le POC | En production |
| --- | --- | --- |
| Utilisateurs | Quelques testeurs volontaires | Une population entière, avec ses usages imprévus |
| Données | Un périmètre délimité | Des sources qui évoluent, à tenir à jour |
| Droits | Souvent simplifiés | Ceux de l'annuaire, appliqués aux documents et aux outils |
| Actions | Lecture et rédaction | Éventuellement des actions dans les outils métier, à faire valider |
| Coûts | Un budget de test | Des enveloppes, des plafonds et un suivi quotidien |
| Exploitation | L'équipe projet | Supervision, support, mises à jour, procédure d'incident |

L'ANSSI, dans ses [recommandations de sécurité pour un système d'IA générative](https://messervices.cyber.gouv.fr/guides/recommandations-de-securite-pour-un-systeme-dia-generative), recommande de prévoir un audit de sécurité et des tests fonctionnels métier avant le déploiement en production (recommandations R23 et R24), ainsi qu'un mode dégradé des services métier sans système d'IA (R15). Ce dernier point est souvent oublié : si le service s'arrête, le travail doit pouvoir continuer.

Deux sujets méritent une décision explicite avant l'ouverture. Les actions qu'un agent peut exécuter dans les outils connectés, et celles qui exigent une confirmation humaine, traitées dans le guide sur la [validation humaine](~/ressources/validation-humaine-agent/). Et les limites de consommation par groupe et par utilisateur, décrites dans le guide [quotas et plafonds de dépense IA](~/ressources/quotas-ia/).

## Déployer par étapes {#deploiement}

- **Pilote élargi** La même population que le POC, plus quelques équipes, sur l'environnement de production, avec les droits réels et les traces actives.
- **Ouverture par population** Groupe par groupe, en commençant par ceux dont le besoin est le plus net, avec des référents formés dans chaque équipe.
- **Mesure continue** Les mêmes critères que pendant le POC, suivis dans la durée : qualité, adoption, coût par tâche, incidents.
- **Cas d'usage suivants** Le deuxième cas réutilise la plateforme, les droits et l'exploitation du premier : c'est là que l'investissement initial se rentabilise.

*Un déploiement progressif, où chaque étape reprend les critères de la précédente.*

Le quatrième point justifie de ne pas traiter chaque cas d'usage comme un projet isolé. Une plateforme commune, avec un catalogue de modèles, des droits et des traces partagés, évite de reconstruire les mêmes couches à chaque fois. C'est l'objet de la [gouvernance de l'IA générative en entreprise](~/ressources/gouvernance-ia/), qui fixe le cadre dans lequel chaque nouveau cas d'usage s'inscrit.

## Les erreurs à éviter {#erreurs}

### Enchaîner les POC sans décider

Multiplier les expérimentations donne une impression d'activité. Sans décision de passage ou d'arrêt à la fin de chacune, l'organisation accumule des démonstrations et aucun service.

### Changer de modèle entre le POC et la production

Les résultats d'un POC valent pour le modèle testé. Un modèle différent, retenu ensuite pour des raisons de coût ou d'hébergement, demande une nouvelle évaluation sur le même échantillon.

### Reporter la question des droits

Un assistant qui a fonctionné en POC avec un accès global aux documents peut exposer, une fois ouvert, des contenus que certains utilisateurs ne devaient pas voir. Les droits réels s'appliquent dès le pilote élargi.

### Mesurer la satisfaction au lieu de l'usage

Des testeurs enthousiastes en réunion n'utilisent pas forcément l'outil trois semaines plus tard. L'usage réel, mesuré, décide.

## Questions fréquentes {#faq}

### Combien de temps doit durer un POC d'IA générative ?

Assez longtemps pour mesurer un usage réel au-delà de l'effet de nouveauté, et pas au point de devenir un service non officiel. La durée se déduit des critères de sortie : il faut le temps de constituer l'échantillon, de tester et d'observer l'adoption sur plusieurs semaines.

### Faut-il faire le POC avec les données de l'entreprise ?

Oui. Un POC sur des données de démonstration mesure un cas qui n'existe pas. C'est justement pour cette raison que l'hébergement et les droits doivent être réglés dès le POC, et non après.

### Qui décide du passage en production ?

Le responsable métier, sur la base des critères fixés avant le test, avec l'avis de la DSI sur l'exploitation, du RSSI sur la sécurité et du DPO lorsque des données personnelles sont traitées.

### Où se situe SmartAGT
SmartAGT se teste en POC chez vous, avec vos modèles et vos données. La plateforme est déployée on-premise : chaque connecteur agit avec les droits du compte connecté, toute action d'écriture ou d'exécution attend une validation humaine, et le coût est suivi par agent, par modèle et par fournisseur.
La licence est annuelle, par utilisateur, toutes capacités incluses : un nouveau cas d'usage n'ajoute pas de module à acheter. Des exemples sont présentés sur la page [Cas d'usage](~/cas-usage/).