Voici le scénario qui se répète actuellement dans l'ensemble de l'industrie : quelqu'un télécharge un cadriciel d'IA agentive à code source ouvert, demande à un assistant de codage en IA de créer rapidement quelque chose et, en quelques heures, obtient une démonstration qui ressemble à un produit fini. Il s'agit d'un phénomène bien réel, qui porte même un nom : le « vibe coding ». Et ce phénomène est convaincant au point où de nombreuses équipes compétentes en ressortent persuadées d'être à quelques semaines de la production. Ce n'est pas le cas.
Ce que le « vibe coding » comprend mal : confiance et état de préparation #
Le « vibe coding », c'est ce qui se produit lorsqu'une personne active un assistant de codage, lui demande de construire une fonctionnalité d'IA agentive, puis observe le résultat. Celui-ci ressemble souvent à une Ferrari. Le biais de confirmation fait le reste : une fois qu'une démonstration donne de bons résultats, il devient tentant de croire qu'elle est prête à être déployée. Or, une démonstration ne répond qu'à une seule question : le concept fonctionne-t-il dans un environnement contrôlé? Elle ne dit rien sur la capacité du système à comprendre votre entreprise, à respecter les exigences de vos organismes de réglementation ou à survivre au contact des données réelles de production.
Pourquoi AutoGen, CrewAI et LangGraph ne suffisent pas en production #
Les cadriciels à code source ouvert sont réellement utiles pour le prototypage, mais c'est exactement là que s'arrête leur valeur pour une industrie réglementée. Certaines lacunes reviennent systématiquement lorsque les assureurs tentent de les déployer en production :
- Une intégration déficiente aux systèmes centraux patrimoniaux, puisque la plupart des cadriciels n'ont jamais été conçus en tenant compte des systèmes d'administration de polices ou de traitement des sinistres.
- Un surajustement à un seul cas d'usage, de sorte que le cadriciel ne comprend que le processus particulier pour lequel il a été conçu, sans rien savoir du reste de l'entreprise.
- Une absence d'explicabilité et de traçabilité, ce qui va directement à l'encontre de ce que les organismes de réglementation attendent des plateformes d'assurance intégrant l'IA.
- Aucune boucle de rétroaction humaine intégrée, ce qui prive les souscripteurs et le personnel chargé des sinistres d'un moyen structuré de corriger ou d'accompagner le système au fil du temps.
- Une exposition sur le plan de la propriété intellectuelle et des licences, puisque le code généré par l'IA peut intégrer des bibliothèques à code source ouvert inconnues, sans que personne ne vérifie ce que contient réellement la pile technologique.
- Aucune base sectorielle prête à l'emploi, comme les règles de souscription propres à chaque État, ce qui signifie que quelqu'un doit tout construire à partir de zéro.
Le vrai travail, ce sont les 95 % restants : dérive, gouvernance et soutien #
Même lorsqu'un cadriciel comble ces lacunes, le problème le plus difficile survient après le lancement. Les grands modèles de langage (GML) changent de comportement d'une version à l'autre, parfois sans grand préavis, et un système qui fonctionnait bien à ses débuts peut s'éloigner discrètement de ce point de référence. Les assureurs ont besoin d'un moyen de mesurer cette dérive, de surveiller la constance des résultats et d'acheminer les problèmes vers une véritable équipe de soutien, comme on le ferait pour tout autre logiciel de production critique. C'est en sautant cette étape que tant de projets pilotes prometteurs s'enlisent avant même d'atteindre l'échelle.
Des recherches récentes chiffrent ce constat : les investissements en IA générative (IAG) ont connu une forte hausse en 2025, mais la majorité des obstacles à la mise à l'échelle signalés par les assureurs n'ont rien à voir avec la technologie elle-même. La culture organisationnelle, les processus et l'état de préparation des données constituent le véritable goulot d'étranglement, soit exactement les 95 % qu'un cadriciel ne peut résoudre à lui seul.
Comment passer de la preuve de concept à la production, de la bonne façon #
Faire fonctionner une démonstration de cadriciel d'intelligence artificielle (IA) est la partie facile. Faire passer une prise de décision propre à l'assurance vers une production sécuritaire et encadrée est un tout autre exercice, qui exige généralement :
- D'observer d'abord les humains, en exécutant l'IA en parallèle des décisions réelles du personnel avant de lui permettre d'agir seule.
- De mesurer la dérive par rapport à un point de référence fixe chaque fois que le modèle répond, et non seulement au lancement.
- D'intégrer des dispositifs de dérogation et de remontée, de sorte qu'une personne puisse toujours intervenir et que le raisonnement demeure traçable.
- De choisir un fournisseur conçu pour le secteur plutôt qu'une plateforme d'IA générique, afin de ne pas avoir à reconstruire à partir de zéro les règles propres à chaque État et la logique de conformité.
- De considérer l'adoption par les employés comme un élément essentiel de l'état de préparation à la production, et non comme une réflexion après coup, puisque le personnel qui se sent remplacé ne fournira pas à l'IA la rétroaction dont elle a besoin pour s'améliorer.
Conclusion #
Le problème, ce n'est pas les cadriciels. C'est plutôt de présumer qu'une démonstration fonctionnelle équivaut à un système prêt pour la production. Les assureurs qui considèrent ces derniers 95 %, soit la gouvernance, la surveillance de la dérive, la révision humaine et le soutien, comme faisant partie intégrante de la portée du projet parviennent à la production. Ceux qui les traitent comme une note de bas de page se retrouvent de retour à l'étape de la preuve de concept.
