POC métier : isoler les prérequis de mise en production

Le POC marche, et pourtant rien ne part en production

La scène est courante. Une équipe monte une preuve de concept en quelques semaines, la démonstration convainc tout le monde, la direction donne son accord de principe. Puis plus rien. Six mois après, l'outil tourne toujours sur le poste de celui qui l'a construit, avec un export de données de l'an dernier, et personne ne sait dire ce qu'il manque pour le mettre entre les mains des équipes.

Ce blocage n'est presque jamais technique au sens strict. Le modèle fonctionne, le code tourne. Ce qui manque, ce sont les conditions d'exploitation : un accès durable aux données, des droits, un hébergement, une personne qui maintient, une décision écrite. Ces conditions, nous les appelons les prérequis de mise en production, et la bonne nouvelle est qu'elles s'identifient pendant le POC, pas après.

Cet article décrit comment isoler ces prérequis dès le départ, famille par famille, pour qu'un POC se termine par une décision claire plutôt que par une attente.

Ce qu'un POC prouve, et ce qu'il ne prouve pas

Un POC métier répond à une question précise : le résultat attendu est-il atteignable sur vos données, avec une qualité acceptable pour le métier. Bien mené, il prouve la faisabilité, il révèle la vraie difficulté du problème et il montre à quoi ressemblerait l'outil.

Il ne prouve rien sur le reste. Il ne dit pas si les données seront accessibles tous les jours, si la direction des systèmes d'information acceptera l'intégration, si le traitement tiendra la volumétrie réelle, si le coût par traitement reste supportable à l'échelle, ni qui corrigera un incident un mardi matin. Confondre les deux est l'erreur qui fabrique les projets bloqués.

D'où une règle simple : un POC a deux livrables, le résultat obtenu et la liste des prérequis pour passer en production. Le second compte autant que le premier.

Écrire le critère de sortie avant de commencer

Avant la première ligne de code, une phrase doit être écrite et validée par celui qui décidera : à quelle condition ce POC déclenche une mise en production, et à quelle condition il s'arrête. Par exemple, que les informations extraites d'un document soient exactes assez souvent pour que la relecture devienne un contrôle rapide plutôt qu'une ressaisie complète, sur un échantillon représentatif choisi à l'avance.

Sans ce critère, le POC se juge à l'impression laissée par la démonstration. Avec lui, la décision se prend sur une mesure, et le non devient possible. Un POC qui s'arrête proprement, avec une raison documentée, coûte beaucoup moins cher qu'un projet qui traîne un an.

Ce critère décrit aussi l'échantillon : combien de cas, choisis comment, incluant les cas difficiles et pas seulement les plus propres. C'est ce qui évite le POC démontré sur cinq documents parfaits.

Les prérequis à isoler pendant le POC

Voici les familles que nous passons en revue pendant un POC. Chacune se traite par une question posée tôt, souvent à quelqu'un d'autre que l'équipe projet, et par une réponse écrite dans le compte rendu.

Les données

• L'accès durable. Le POC tourne souvent sur un export envoyé une fois. En production, il faut un accès qui se renouvelle : une base, une interface de programmation, un dépôt de fichiers alimenté automatiquement. Qui l'ouvre, sous quel délai, avec quelle authentification.
• La fraîcheur. À quel rythme la donnée doit être à jour pour que l'outil soit utile : en direct, dans l'heure, le lendemain matin.
• La qualité et les cas limites. Ce que contiennent réellement les données quand on sort de l'échantillon : champs vides, doublons, formats hérités, documents scannés de travers.
• La volumétrie réelle. Le nombre de lignes, de documents et d'utilisateurs attendus, avec les pics. Le POC tourne sur un cas, la production sur le flux.
• Le droit d'usage. Ce que l'entreprise a le droit de faire de ces données, en particulier si elles viennent de clients ou de partenaires.

Les accès et les identités

• Qui se connecte et comment. Compte d'entreprise existant, annuaire, double authentification.
• Qui voit quoi. Les rôles et les périmètres : une agence ne voit pas les dossiers d'une autre, un profil consulte sans modifier.
• Les départs et arrivées. Comment un accès se crée et surtout se retire quand quelqu'un change de poste.

L'intégration au système existant

• Les points de contact. Quels logiciels l'outil doit lire ou alimenter : ERP, CRM, outil métier, messagerie.
• Les interlocuteurs. Qui, côté informatique ou côté éditeur, ouvre ces accès, et sous quel délai. C'est souvent le prérequis le plus long, donc celui qu'il faut lancer en premier.
• Les environnements. Existe-t-il un environnement de test, ou faut-il valider directement sur les données réelles, avec les précautions que cela impose.
• Les fenêtres de mise en service. Périodes de gel, clôtures comptables, saison haute pendant laquelle rien ne bouge.

La sécurité et la conformité

• La nature des données. Données personnelles, données sensibles, secrets industriels. Cela détermine l'hébergement, les durées de conservation et les traces à garder.
• Le lieu d'hébergement et les sous-traitants. Où tournent l'application et le modèle, qui sont les prestataires, ce que dit le contrat sur la réutilisation des données. Notre article sur l'hébergement d'un projet IA en France présente les options.
• Les obligations réglementaires. Registre des traitements, analyse d'impact quand elle est requise, information des personnes, et les obligations de transparence décrites dans notre article sur l'AI Act pour les PME.
• La journalisation. Ce que l'outil enregistre de chaque traitement, pour pouvoir expliquer une décision plus tard.

La fiabilité et l'exploitation

• Le niveau de service attendu. Ce qui se passe si l'outil est indisponible une heure, une journée. Souvent, la réponse est « on fait comme avant », et cela simplifie tout le reste.
• La supervision. Qui est prévenu quand un traitement échoue, et par quel canal.
• Les sauvegardes et la reprise. Ce qui est sauvegardé, à quelle fréquence, et comment on restaure.
• Le support. À qui s'adresse un utilisateur bloqué, avec quel délai de réponse.

Le coût et la performance

• Le coût par traitement. Sur un POC, la facture du modèle est anecdotique. À l'échelle, elle devient un poste. Il se mesure pendant le POC, puis se multiplie par la volumétrie réelle. Notre article sur le coût d'un agent IA en production détaille les postes.
• Le temps de réponse acceptable. Une réponse attendue à l'écran et un traitement de nuit ne se conçoivent pas de la même façon.
• Les plafonds. Ce qui se passe quand la consommation dépasse ce qui était prévu : alerte, file d'attente, arrêt.

La qualité du résultat, quand il y a de l'IA

• Le jeu d'évaluation. Un ensemble de cas avec la réponse attendue, constitué pendant le POC et conservé. C'est ce qui permettra de vérifier qu'une mise à jour du modèle n'a rien cassé.
• Le seuil d'acceptation. Le niveau de justesse au-delà duquel le métier accepte de s'appuyer sur l'outil.
• La place de l'humain. Ce qui est validé par une personne avant d'avoir un effet, et ce qui passe tout seul. Notre mémo IA responsable décrit les principes que nous appliquons.
• Le comportement hors périmètre. Ce que fait l'outil quand il ne sait pas : il le dit et passe la main, plutôt que de produire une réponse plausible.

L'appropriation et la suite

• Le porteur côté métier. Une personne nommée, qui arbitre et qui répond aux questions courantes.
• La formation. Sur l'outil réel, avec les données de l'équipe, pas sur une présentation.
• La maintenance. Qui corrige et qui fait évoluer, avec quel accès au code et à l'hébergement. La propriété du code et des données se décide avant la production, pas au moment d'un désaccord.
• La mesure d'usage. Comment on saura, dans trois mois, que l'outil sert vraiment.

Les cinq pièges les plus fréquents

• Le POC sur données d'exemple. Il prouve que la technique marche, pas que votre cas marche. Utilisez vos vraies données dès que possible, avec le cadre juridique qui va avec.
• Le POC qui tourne sur un poste. Tant que rien n'est hébergé, aucun prérequis d'exploitation n'a été rencontré, donc aucun n'a été traité.
• Le POC jamais mesuré. Sans critère écrit à l'avance, la décision devient une affaire d'opinion, et l'opinion se déplace à chaque réunion.
• Le prototype promu en production par accident. Un outil utilisé tous les jours qui n'a ni sauvegarde, ni droits, ni supervision. C'est la situation la plus risquée, parce que personne ne l'a décidée.
• Les accès demandés trop tard. L'ouverture d'un accès à un système interne prend souvent plus de temps que le développement lui-même. C'est la première demande à envoyer, pas la dernière.

Un POC n'est pas une démonstration commerciale

La confusion est fréquente, parce que les deux se terminent par une présentation. Une démonstration cherche à convaincre : elle montre le meilleur cas, sur des données choisies, avec un récit soigné. Un POC cherche à savoir : il va chercher les cas qui font mal, il mesure, et il accepte de conclure par un non.

Cette différence se voit dans ce qu'on présente. Sur un POC, la partie la plus intéressante n'est pas la démonstration qui marche, ce sont les cas qui ont échoué et ce qu'ils révèlent : un format de document non prévu, une règle métier que personne n'avait formulée, une donnée absente du système. Ces échecs ont une valeur, parce qu'ils sont exactement ce qui aurait fait dérailler le projet six mois plus tard.

Un POC réussi peut donc parfaitement se terminer par un arrêt. Ce qui compte n'est pas que la réponse soit oui, c'est que la réponse soit fondée et que la décision revienne à celui qui engage l'argent.

Trois questions avant de lancer la production

Au moment de la décision, trois questions suffisent à savoir si les prérequis sont réellement traités, ou simplement listés.

• Si l'outil tombe demain matin, que fait l'équipe ? Une réponse claire, même si c'est « on reprend le tableur pour la journée », prouve que le sujet a été regardé. Une hésitation montre que l'exploitation n'a pas été pensée.
• Qui ouvre les accès, et quand ? Un nom et une date. Sans les deux, le calendrier de la production est une estimation qui ne tient pas.
• Comment saura-t-on dans trois mois que ça a marché ? Une mesure choisie avant la mise en service, comparable à un relevé fait avant. Sans elle, l'outil sera jugé sur les impressions du moment.

Ce que contient un compte rendu de POC utile

À la fin d'un POC, le document remis tient en quelques pages et contient toujours les mêmes éléments : la question posée, le critère de sortie écrit au départ, la mesure obtenue sur l'échantillon, la liste des prérequis par famille avec pour chacun un responsable et un délai, une estimation de la charge restante, et une recommandation tranchée, aller en production, ajuster le périmètre ou arrêter.

Ce document a une autre vertu : il se lit par une direction qui n'était pas dans la salle. C'est souvent lui qui débloque la décision, plus que la démonstration elle-même.

Comment nous procédons

Nos ingénieurs travaillent chez le client pendant le POC, au contact des utilisateurs, ce qui permet de rencontrer les prérequis en situation plutôt que de les deviner. Les demandes d'accès partent la première semaine. Le jeu d'évaluation se construit avec le métier, pas à côté. Le POC est hébergé, même modestement, pour que la question de l'exploitation se pose tout de suite.

La suite dépend du résultat. Les pages méthode agent IA et méthode application complète décrivent ce qui se passe après le feu vert, et notre article sur le déploiement d'un agent IA en entreprise détaille les étapes réelles, du cadrage au débrief. La page accompagnement situe le prototype parmi les cinq étapes de maturité.

Pour savoir si votre sujet mérite un POC, et lequel, notre diagnostic IA pose les bonnes questions en quelques minutes.

Questions fréquentes

Combien de temps doit durer un POC métier ?

Assez pour mesurer le critère de sortie sur un échantillon représentatif, et pas plus. La durée se fixe au cadrage, avec une date de décision. Un POC sans date de fin devient un projet sans décision.

Faut-il faire le POC sur des données réelles ?

Oui dès que le cadre juridique le permet, car les vraies données portent les cas limites qui font la difficulté du projet. À défaut, sur un échantillon réel anonymisé, en prévoyant une vérification sur données complètes avant la production.

Quel est le prérequis qui bloque le plus souvent ?

L'ouverture des accès aux systèmes internes. Elle dépend d'équipes qui ne sont pas dans le projet et prend souvent plus de temps que le développement. C'est la première demande à envoyer.

Un POC réussi peut-il être mis en production tel quel ?

Rarement. Il a été construit pour répondre à une question, pas pour tenir la charge, les droits et la reprise après incident. Une partie du code se garde, le reste se reconstruit avec les prérequis d'exploitation.

Que faire si le POC ne tient pas son critère de sortie ?

L'arrêter ou réduire le périmètre, et le documenter. Un non argumenté est un résultat utile : il évite un projet qui coûterait sans rendre le service attendu, et il indique souvent quel autre sujet mérite le POC suivant.