L'écart entre une bonne démo et une fonctionnalité livrée
En 2026, chaque entreprise à qui nous parlons a déjà vu la démo. Quelqu'un dans l'équipe a branché un LLM sur un tableur, ou construit un chatbot sur la documentation interne en un week-end, et ça a fait sensation à la réunion générale. Puis l'outil est resté trois mois dans un canal Slack, jamais utilisé en production, parce que personne ne pouvait répondre à la question : que se passe-t-il quand il se trompe devant un client, ou pire, devant un auditeur ?
Cet écart — entre « le modèle a produit une bonne réponse une fois » et « ceci tourne sans supervision sur des données réelles, pour des utilisateurs réels, tous les jours » — c'est là que va concrètement presque tout notre temps d'engagement en IA/ML. Écrire le prompt prend un après-midi. Le rendre sûr à laisser tourner, c'est le vrai projet.
Voici ce qui sépare réellement une démo d'un système en production, et ce que ça coûte de combler cet écart.
Les démos sautent les étapes qui garantissent la fiabilité
Une démo, c'est une entrée, exécutée une fois, par quelqu'un qui sait comment formuler la question. La production, ce sont des milliers d'entrées imprévisibles, exécutées en continu, par des gens qui ignorent — et n'ont pas à savoir — comment le modèle fonctionne. Trois choses cassent en premier quand on fait ce saut :
1. Impossible de savoir si un changement de prompt a amélioré ou dégradé les résultats. Sans un jeu de tests fixe avec des résultats attendus — un eval set — chaque ajustement de prompt est un pari. Nous construisons un eval set à partir de vraies questions d'utilisateurs avant de toucher un prompt en production, et nous le rejouons à chaque changement de modèle ou de prompt. Si un client ne peut pas nous dire que le taux de réussite est passé d'un chiffre à un meilleur chiffre, il ne peut pas déployer un changement en toute sécurité — il ne fait qu'espérer.
2. Le modèle ne vaut que ce qu'il peut retrouver. Pour tout ce qui s'appuie sur vos propres données — documentation support, contrats, wikis internes — la qualité de la recherche compte plus que le modèle appelé. Un découpage naïf associé à une simple recherche vectorielle donne une démo qui fonctionne sur les trois questions testées. Le RAG en production a besoin d'une recherche hybride (mots-clés plus vecteurs), d'un reranking, et d'une exigence stricte : chaque réponse doit citer son document source. Si le système ne peut pas indiquer d'où vient une réponse, ne le déployez sur aucune fonctionnalité destinée aux clients.
3. Les agents qui utilisent des outils ont besoin d'un modèle de permissions, pas seulement d'un prompt. Dès qu'un agent peut créer un remboursement, mettre à jour une fiche CRM, ou envoyer un e-mail au nom de quelqu'un, « le modèle a décidé de » cesse d'être une explication acceptable. Chaque action a besoin d'un périmètre défini : ce que l'agent peut faire seul, ce qui nécessite une validation humaine, et ce qu'il ne doit jamais toucher. Nous maintenons une liste explicite d'interdictions pour chaque agent que nous construisons — généralement tout ce qui est irréversible ou financier — avant même d'écrire la première définition d'outil.
Le mode de défaillance que personne n'anticipe : la réponse fausse mais sûre d'elle
Une panne d'API, ça se voit. Un modèle qui répond avec aisance et se trompe, non. C'est le risque spécifique qui tue la confiance dans une fonctionnalité IA plus vite que tout le reste — une seule réponse erronée livrée avec une confiance totale, et l'équipe qui portait le projet passe le trimestre suivant à le défendre.
La solution n'est pas un meilleur modèle. Elle est structurelle : exiger des citations pour tout ce qui s'appuie sur vos données, ajouter un seuil de confiance qui redirige les réponses incertaines vers un humain plutôt que de deviner, et journaliser chaque prompt, chaque recherche et chaque complétion pour pouvoir reconstituer exactement ce qui s'est passé quand quelque chose tourne mal. Nous traitons cette couche de journalisation comme non négociable, au même titre que la journalisation des erreurs sur un flux de paiement. Personne n'y prête attention jusqu'au jour où on en a désespérément besoin.
L'automatisation interne, le retour sur investissement IA le plus rapide en ce moment
Les agents orientés client attirent l'attention, mais le travail IA le plus fiable que nous menons en 2026 est interne : trier les tickets support entrants avant qu'un humain ne les voie, résumer les appels commerciaux en notes CRM, extraire les lignes d'articles de factures et de contrats, et permettre aux équipes de poser des questions sur la documentation interne plutôt que de solliciter un canal Slack. Les enjeux sont plus faibles — un outil interne occasionnellement dans l'erreur est corrigé par un collègue, pas par un client — donc les garde-fous peuvent être plus légers et le retour sur investissement plus rapide.
Un assistant RAG ciblé sur la documentation propre d'une entreprise représente concrètement un engagement de $7,000+, avec un prototype fonctionnel en 2 à 4 semaines, et une version durcie pour la production — authentification, journalisation, eval set, citations de sources — en 8 à 12 semaines. Les agents utilisant des outils connectés à des systèmes réels (un CRM, un système de ticketing, un ERP) démarrent autour de $20,000+, car le travail de permissions et de tests évolue avec ce que l'agent est autorisé à toucher. L'automatisation pure de workflows — sans modèle dans la boucle, juste un déplacement fiable de données entre outils — démarre plus bas, à partir de $3,000 pour une seule intégration.
Ce que nous exigeons avant d'écrire le premier prompt
Sur chaque engagement IA, quatre décisions sont prises avant que le moindre code ne soit livré, pas après :
- Un responsable pour l'eval set. Quelqu'un dont le travail consiste à remarquer une baisse de qualité, pas « l'équipe » de façon abstraite.
- Une liste documentée d'interdictions. Les actions précises que le système n'est jamais autorisé à entreprendre sans confirmation humaine préalable.
- Un plafond de coût. Des budgets de tokens par utilisateur ou par jour, avec des alertes avant que la facture ne surprenne qui que ce soit. Un tri par modèle économique associé à une escalade vers un modèle de pointe, pas un modèle de pointe sur tout.
- Un plan de retour en arrière. Les fournisseurs de modèles changent de comportement sous un nom d'API stable plus souvent qu'on ne le pense. Si la précision chute après une mise à jour silencieuse du fournisseur, il faut disposer d'une version précédente du prompt et d'un score d'eval précédent pour comparer.
Sautez l'une de ces étapes et le projet n'échoue pas bruyamment — il échoue silencieusement, des semaines après le lancement, quand quelqu'un remarque que le système se trompe avec assurance depuis un moment et que personne ne surveillait.
En résumé
En 2026, le modèle est rarement le goulot d'étranglement. Les API de pointe d'OpenAI et d'Anthropic, associées à des frameworks de récupération comme LlamaIndex et des bases vectorielles comme pgvector, suffisent largement pour l'immense majorité des cas d'usage métier. Ce qui détermine si une fonctionnalité IA survit au contact des utilisateurs réels, c'est l'ingénierie peu spectaculaire qui l'entoure : evals, ancrage aux données, permissions, journalisation, et un modèle de coût qui ne surprend pas la finance.
C'est le travail que mène notre équipe IA & machine learning — transformer une démo qui fonctionne en un système qu'une entreprise peut réellement faire tourner sans supervision. Si le volet automatisation interne vous intéresse davantage — connecter des outils et éliminer le travail répétitif plutôt que construire une nouvelle fonctionnalité IA — notre équipe automatisation & intégrations scope ces projets de la même façon : prototyper vite, durcir avant que ça ne touche à quelque chose de critique.
