Le prototype a fait l’unanimité en comité de direction. Six mois plus tard, il tourne encore sur le poste d’un développeur : personne ne l’utilise et plus personne n’ose y toucher. Ce scénario ne signifie pas que l’idée était mauvaise. Il signifie que le vrai travail n’a pas encore commencé.
Lors de la démonstration, l’assistant répondait en quelques secondes aux questions sur les contrats fournisseurs, citait ses sources et reformulait avec élégance. Le directeur général a demandé quand les équipes achats pourraient y accéder. Le CTO a répondu « bientôt ». C’était en mars.
En septembre, le prototype n’a toujours pas quitté son environnement de test. Il fonctionne avec une copie des contrats extraite à la main, ignore les droits d’accès et a été construit par un développeur qui a depuis quitté l’entreprise. Personne ne sait combien il coûterait avec deux cents utilisateurs, ni s’il répond juste au-delà des dix exemples de la démonstration.
Votre POC n’est probablement pas à jeter : il a prouvé qu’un usage était faisable. Mais il n’a pas démontré qu’il pouvait devenir un service. Reprendre un POC IA consiste précisément à combler cet écart.
Pourquoi tant de POC IA n’arrivent-ils jamais en production ?
Gartner prévoyait qu’au moins 30 % des projets d’IA générative seraient abandonnés après la preuve de concept d’ici fin 2025. Les causes identifiées — données de mauvaise qualité, contrôles de risque insuffisants, coûts qui s’envolent et valeur métier mal établie — concernent surtout ce qui se passe après la démonstration.
La raison est structurelle. Un POC répond à une question simple : « Est-ce faisable ? » Il est donc construit vite, sur des données choisies et sans toutes les contraintes d’un système réel. Ce n’est pas un défaut : c’est sa fonction.
Le problème survient lorsqu’on confond cette réponse avec une autre, beaucoup plus exigeante : « Nos équipes peuvent-elles s’en servir chaque jour, sur des données réelles, en toute sécurité et à un coût maîtrisé ? »
Un POC prouve qu’une idée est possible. Il ne prouve pas qu’elle est exploitable. Entre les deux, il faut intégrer la solution aux outils, gérer les droits, mesurer la qualité, superviser le service, maîtriser les coûts et documenter son fonctionnement. Les entreprises qui sous-estiment cet écart restent dans le « purgatoire du POC » : le prototype semble trop prometteur pour être abandonné, mais trop fragile pour être déployé.
Que ne vous apprend pas un POC IA ?
Un prototype d’assistant, d’agent ou d’extraction documentaire répond souvent bien sur quelques exemples choisis. En production, il rencontre aussi les documents incomplets ou mal numérisés, les questions imprévues, les utilisateurs aux droits différents, des volumes plus importants et des coûts qui s’accumulent.
Il ne révèle pas nécessairement comment la solution se comporte lorsqu’elle ne sait pas. Pourtant, un assistant qui invente une clause contractuelle avec aplomb est plus dangereux qu’un assistant qui répond : « Je ne trouve pas cette information dans les documents disponibles. » Ce comportement se conçoit, se teste et se mesure.
Enfin, un POC ne dit rien de sa longévité. Les fournisseurs publient de nouvelles versions de modèles et en retirent d’anciennes. Les documents évoluent ; un changement de prompt peut améliorer un cas et en dégrader dix autres. Sans dispositif de contrôle, la qualité peut dériver silencieusement.
Quels signaux indiquent qu’il est temps de reprendre votre POC ?
Quatre situations reviennent fréquemment. La première : le prototype plaît, mais personne ne l’utilise. Il reste à côté des outils métier, sans authentification ni données à jour, et oblige chacun à quitter son environnement de travail. Il faut alors l’intégrer au parcours réel des équipes.
La deuxième : les réponses sont imprévisibles. Sans jeu d’évaluation, impossible de savoir si une modification a amélioré ou dégradé la solution. La troisième : coûts ou délais dérivent — appels aux modèles non maîtrisés, temps de réponse trop longs ou traitement documentaire coûteux. L’architecture doit être revue avant la montée en charge. La quatrième : l’équipe qui a construit le POC n’est plus disponible, le code n’est pas documenté et les choix techniques ne sont plus expliqués.
Pour un dirigeant — Posez trois questions à votre équipe : combien d’utilisateurs se servent réellement du prototype chaque semaine ? Comment sait-on que ses réponses sont justes ? Combien coûterait-il par mois s’il était ouvert à toute l’entreprise ? Si aucune réponse n’est chiffrée, votre POC a besoin d’une reprise.
Faut-il reprendre, reconstruire ou arrêter le POC ?
Tout POC ne mérite pas d’être industrialisé. Le diagnostic initial sert à choisir entre trois options.
La première est la reprise : le code et l’architecture sont assez sains pour être conservés, restructurés et complétés. C’est notamment le cas lorsqu’une équipe compétente a simplement manqué de temps.
La deuxième est la reconstruction partielle. Certaines briques, comme la logique de recherche documentaire ou les prompts, ont de la valeur, mais le socle technique ne tiendra pas la charge ou ne peut pas être sécurisé. On conserve les enseignements et les éléments qui fonctionnent, puis on reconstruit le reste sur des bases solides. C’est fréquent avec les prototypes produits rapidement par des outils no-code ou du code assisté par IA, comme nous l’expliquons dans notre article sur le passage d’un projet vibe coded à un produit en production.
La troisième option est l’arrêt — ou, plus exactement, le changement d’approche. Une recherche classique ou une automatisation déterministe répond parfois mieux au besoin, pour un coût inférieur. Recommander de ne pas industrialiser un POC fait aussi partie du diagnostic.
Comment se déroule une reprise de POC IA ?
La démarche s’organise en quatre étapes. Chacune donne lieu à des livrables que vous validez avant d’engager la suivante.
Le diagnostic du POC
Nous examinons le code, les données, les prompts, les modèles utilisés, les résultats obtenus et les limites observées. Nous échangeons avec les personnes qui ont construit le prototype, si elles sont disponibles, ainsi qu’avec les utilisateurs pressentis. Vous obtenez les risques classés par gravité, une recommandation entre reprise, reconstruction partielle ou changement d’approche, et un plan priorisé et chiffré.
Le jeu d’évaluation et les critères de réussite
Avec vos équipes métier, nous définissons des exemples de référence et des seuils attendus. Ce jeu devient le juge de paix du projet : chaque évolution est mesurée par rapport à lui, plutôt que jugée sur des impressions. Il est conservé et enrichi pendant toute la vie du service.
L’industrialisation
Architecture, tests, sécurité, intégration aux outils, supervision et documentation : le prototype change ici de nature. Les évolutions sont livrées par étapes et démontrées, afin que vos équipes puissent suivre concrètement l’avancement.
La mise en production et le suivi
La mise en service est progressive : un groupe d’utilisateurs pilotes d’abord, puis un élargissement une fois les indicateurs stabilisés. Le suivi porte sur la qualité des réponses, les erreurs, les temps de traitement et la consommation. Les retours utilisateurs alimentent les évolutions suivantes.
Comment mesurer la qualité d’une IA autrement qu’à l’impression ?
C’est l’une des différences les plus nettes entre un POC et un service en production. Dans un prototype, la qualité est jugée à l’œil, sur quelques essais. En production, elle doit être mesurable, répétable et comparable dans le temps.
Avec vos experts métier, nous constituons un ensemble d’exemples représentatifs : questions courantes, cas difficiles, documents ambigus et demandes auxquelles la solution doit refuser de répondre, parce que l’information n’existe pas ou que l’utilisateur n’y a pas droit. Pour chaque exemple, on définit ce qu’est une bonne réponse. Les évaluations sont rejouées automatiquement après chaque changement de modèle, de prompt ou de données.
Sans jeu d’évaluation, chaque amélioration est un pari. Avec, c’est une décision. On peut constater, par exemple, une progression sur les réponses correctes tout en repérant les cas de refus qui régressent. La discussion entre technique et métier devient factuelle, et la confiance des utilisateurs repose sur des éléments tangibles.
Comment maîtriser le coût d’une IA en production ?
Les coûts d’un service IA sont variables et proportionnels à l’usage. Chaque question ou document traité peut générer des appels facturés par le fournisseur du modèle. Un prototype utilisé par trois personnes ne permet donc pas de prévoir la facture d’un service utilisé par trois cents.
Plusieurs leviers aident à rendre le coût prévisible. Choisir un modèle adapté à chaque étape : un modèle léger pour classer ou router une demande, un modèle plus puissant uniquement lorsque la qualité l’exige. Limiter le contexte transmis en envoyant les passages utiles plutôt que des documents entiers. Mettre en cache les résultats qui peuvent l’être. Enfin, suivre la consommation et configurer des alertes en cas de dérive. Ces optimisations peuvent réduire significativement le coût unitaire sans dégrader la qualité mesurée.
Pour un CTO — Demandez un coût par requête et par utilisateur actif, ventilé par étape de traitement, ainsi qu’une projection à trois volumes d’usage. C’est une base sérieuse pour arbitrer entre modèles et présenter le projet à la direction financière.
Quels sont les angles morts de sécurité d’un prototype ?
La sécurité est rarement la priorité d’un POC, dont le but est de prouver une faisabilité, pas d’ouvrir un service. Mais elle doit être traitée avant tout déploiement. Les angles morts sont souvent les mêmes.
L’authentification peut être absente ou reposer sur un mot de passe partagé. Les droits d’accès sont parfois ignorés : le prototype interroge les données avec un compte technique qui voit tout, ce qui peut permettre à un utilisateur d’obtenir une information inaccessible dans l’outil d’origine. Des secrets, comme les clés d’API, peuvent être inscrits en clair dans le code.
Enfin, la protection contre les instructions malveillantes est souvent absente. Un document ou un e-mail peut contenir un texte conçu pour détourner le modèle — un risque critique dès que la solution peut agir sur des systèmes. La reprise traite ces sujets de façon systématique et met en place des traces des appels aux modèles, utiles aussi pour l’audit et la conformité. Pour approfondir ces enjeux, consultez notre article sur les précautions à prendre face aux risques de l’IA en entreprise.
Peut-on reprendre le POC d’un autre prestataire ?
Oui, et c’est une situation courante. Les POC que nous reprenons ont été construits par des équipes internes, d’autres prestataires, des stagiaires, des outils no-code ou du code généré avec l’aide de l’IA. Leur origine importe peu. Ce qui compte, c’est l’accès au code, aux données utilisées, aux prompts et, si possible, aux résultats des essais.
Nous gardons ce qui fonctionne, restructurons ce qui ne tiendra pas la charge et ajoutons ce qui manque. Le diagnostic indique ce qui peut être conservé, ce qui doit être reconstruit et l’effort nécessaire pour atteindre la production. Si la reprise soulève des questions d’architecture plus larges, un audit technique ou un accompagnement CTO as a Service peut compléter l’intervention.
Que récupérez-vous à la fin d’une reprise ?
Une reprise réussie ne se limite pas à un service qui fonctionne. Elle vous laisse un système compréhensible et transmissible : le diagnostic et le plan de reprise, le jeu d’évaluation avec les résultats mesurés, le code, la configuration et la documentation d’exploitation. Ces éléments vous appartiennent et permettent à toute équipe compétente — y compris la vôtre — de reprendre le service.
Si le périmètre est clair et stable, la reprise peut être menée en projet au forfait, avec budget et livrables définis à l’avance. Si le service doit évoluer en continu, s’enrichir de nouvelles sources ou couvrir de nouveaux cas d’usage, une équipe dédiée d’ingénieurs francophones à Madagascar et à Maurice, pilotée depuis la France, peut assurer son développement et sa maintenance dans la durée.
Les applications que nous exploitons nous-mêmes, comme notre assistant connecté à l’ERP ou l’agent de synthèse du dossier médical, suivent ce cadre. Si votre projet n’en est pas encore au stade du prototype, notre article sur l’intégration de l’IA en entreprise détaille comment cadrer un premier cas d’usage.
Le prochain avantage concurrentiel ne viendra pas d’une démo de plus
Toutes les entreprises ont désormais accès aux mêmes modèles. Fabriquer un prototype impressionnant n’a jamais été aussi simple — et c’est précisément pourquoi cela ne distingue plus personne. L’écart se creuse entre les organisations qui accumulent les démonstrations et celles qui savent transformer un prototype en service mesuré, sécurisé et utilisé chaque jour.
Votre POC a peut-être déjà parcouru la partie la plus visible du chemin. Reste à décider si vous êtes prêt à faire la partie qui compte vraiment, ou si vous préférez lui laisser une place d’honneur parmi les projets qui auraient pu changer quelque chose.
Découvrez notre offre de reprise de POC IA ou échangez avec notre équipe pour évaluer la suite à donner à votre prototype.
Reprendre un POC IA : questions fréquentes
Qu’est-ce qu’un POC IA, concrètement ?
Un POC (proof of concept) IA est un prototype qui démontre qu’un usage de l’IA est faisable sur quelques exemples. Il valide une idée, mais ne comprend généralement pas l’intégration, la sécurité et l’exploitation nécessaires à un usage réel.
Combien de temps faut-il pour remettre un POC IA en production ?
Cela dépend de l’état du prototype, de l’accès aux données et des intégrations nécessaires. Un diagnostic permet d’établir un plan de reprise par étapes et de chiffrer le travail à engager.
Le code d’un stagiaire ou d’un outil no-code peut-il être conservé ?
Oui, si le diagnostic montre que certaines briques sont suffisamment saines et utiles. Le code, les prompts ou la logique de recherche peuvent être conservés, tandis que le socle fragile est restructuré ou reconstruit.
Qui définit les critères de réussite d’une solution IA ?
Les équipes métier et techniques les définissent ensemble à partir d’exemples représentatifs. Elles précisent ce qu’est une réponse correcte, les cas difficiles et les situations où la solution doit s’abstenir.
Faut-il toujours industrialiser un prototype qui fonctionne ?
Non. Le diagnostic peut conclure qu’une recherche classique ou une automatisation déterministe répond mieux au besoin, avec un coût et un risque moindres.
