Point clé
Une suite d'évaluations bâtie à partir de vos vrais cas d'usage, une surveillance en production et des contrôles de sécurité : c'est ce qui vous permet de livrer vos changements IA avec la même confiance que n'importe quelle autre version.
La démo s’est bien passée. Quelqu’un de votre équipe a branché un modèle sur vos données en quelques sprints, et le PDG l’a présentée au conseil d’administration. Maintenant, il y a une date de lancement.
Puis les premiers utilisateurs bêta arrivent. Ils collent un PDF de 40 pages au lieu d’un paragraphe. Ils posent leurs questions en français. L’un d’eux tape « ignore your previous instructions » juste pour voir ce qui va se passer. Votre développeur modifie un prompt pour régler une plainte et brise discrètement deux autres choses que personne ne remarque pendant une semaine.
Rien de cela ne veut dire que le prototype était une erreur. Un prototype répond à une seule question : est-ce que ça peut fonctionner? La production en pose d’autres, et la plupart des équipes les découvrent un incident à la fois.
Pourquoi les prototypes bloquent avant le lancement
Les prototypes sont construits dans des conditions idéales. Des entrées propres, une poignée de cas de test, un seul utilisateur qui sait exactement comment formuler ses demandes. Le développeur qui l’a bâti vérifie les résultats en les lisant.
Cette approche ne tient plus quand l’utilisation augmente. Vous ne pouvez pas lire chaque réponse. Impossible aussi de vous souvenir de chaque cas limite. Et le comportement d’un LLM n’est pas déterministe : un test qui passe aujourd’hui peut échouer demain avec la même entrée.
La plupart des équipes se heurtent aussi à un problème de ressources. Le développeur qui a bâti le prototype a une feuille de route qui l’attend. Le travail qui reste n’a rien de glorieux : bancs d’essai, journalisation, modélisation des menaces, logique de relance. C’est du vrai génie logiciel, et il entre en concurrence avec toutes les autres priorités.
Alors le prototype reste derrière un feature flag pendant un trimestre. Ou il est livré sans garde-fous, et l’équipe passe le trimestre suivant à éteindre des feux.
Ce que nous construisons
Nous prenons votre prototype fonctionnel et nous bâtissons autour la couche qui permet de le mettre devant vos clients en toute sécurité. Le modèle et la logique de base restent clairement les vôtres. Ce qui change, c’est tout ce qui vous indique si ça fonctionne.
Une suite d’évaluations bâtie à partir de vos vrais cas d’usage
Les évaluations sont la fondation. Sans elles, chaque modification de prompt est un pari.
Nous commençons par recueillir de vraies entrées : journaux de la bêta, billets de support, exemples que votre équipe produit juge « bons » ou « mauvais ». À partir de là, nous bâtissons un jeu de données étiqueté qui couvre vos parcours courants et les cas limites qui vous inquiètent.
Ensuite, nous écrivons des évaluateurs. Certains sont déterministes : ils vérifient que la sortie est un JSON valide, que l’identifiant d’un document cité existe ou qu’un refus survient quand il le faut. D’autres utilisent un modèle comme juge, noté selon une grille que votre équipe approuve. Là où le jugement compte le plus, nous calibrons les notes du modèle-juge avec des étiquettes humaines. Vous savez ainsi jusqu’à quel point vous y fier.
La suite s’exécute dans la CI à chaque changement de prompt, de modèle, de paramètres de récupération ou de définition d’outil. Une pull request qui fait baisser la précision sur les questions de facturation est signalée avant d’être fusionnée, comme le serait un test unitaire en échec.
Les mises à niveau de modèle deviennent aussi ennuyantes, et c’est exactement ce que vous voulez. Quand une nouvelle version sort, vous lancez la suite et vous comparez. Vous obtenez un chiffre plutôt qu’un débat.
Surveillance et traçage en production
Un outil APM traditionnel vous dit qu’une requête a pris 4 secondes et retourné un code 200. Il ne vous dit pas que la réponse était mauvaise.
Nous instrumentons tout le parcours de la requête avec du traçage : l’entrée de l’utilisateur, le contexte récupéré, chaque appel au modèle, chaque appel d’outil, le nombre de jetons et la latence à chaque étape. Quand un client signale une mauvaise réponse, votre équipe peut sortir la trace et voir exactement où ça a dérapé. La récupération était-elle mauvaise? Le modèle a-t-il ignoré un bon contexte? Un outil a-t-il renvoyé une erreur passée sous silence?
En plus du traçage, nous mettons en place les métriques qui comptent pour les fonctionnalités IA en particulier :
- Les signaux de qualité, dont des évaluations en ligne par échantillonnage et la rétroaction des utilisateurs, comme les pouces vers le bas ou les clics sur « régénérer »
- Le coût par requête et par client, pour qu’un prompt qui s’emballe n’apparaisse pas d’abord sur votre facture
- Les percentiles de latence ventilés par étape, pour savoir si le goulot d’étranglement est le modèle ou votre récupération
- Les modes de défaillance, comme les refus, les réponses vides, les sorties mal formées et les délais dépassés
Les alertes arrivent là où votre équipe regarde déjà. Si vous utilisez Datadog ou Grafana, nous nous branchons dessus plutôt que d’ajouter un autre tableau de bord que personne n’ouvre.
Contrôles de sécurité
Toute fonctionnalité qui transmet des entrées utilisateur à un modèle ouvre une nouvelle surface d’attaque. Les équipes de sécurité le savent, et elles vont poser des questions.
L’injection de prompt est la plus évidente. Un utilisateur, ou un document qu’il a téléversé, contient des instructions destinées à contourner votre prompt système. Nous traitons ce risque par couches. Le contenu non fiable est clairement séparé des instructions. Les entrées sont filtrées pour repérer les patrons d’injection connus. Surtout, les permissions du modèle sont restreintes pour qu’une injection réussie ne puisse pas faire grand-chose. Si le modèle peut seulement lire les données que l’utilisateur courant a déjà le droit de voir, un prompt système qui fuit devient un embarras, pas une brèche.
Nous couvrons aussi les fuites de données. Cela veut dire gérer les renseignements personnels dans les journaux et les traces, vérifier que les données d’un client n’apparaissent jamais dans le contexte d’un autre et filtrer les sorties là où votre domaine l’exige. Si vous envoyez des données à un fournisseur de modèles externe, nous documentons ce qui va où, pour que votre revue de sécurité ait du concret sur quoi s’appuyer.
Une architecture qui tient la vraie charge
Les prototypes appellent généralement le modèle de façon synchrone, en espérant que tout aille bien. La production demande plus de soin.
Nous ajoutons des relances avec délai progressif (backoff) pour les erreurs du fournisseur et les limites de débit. Des solutions de repli, comme un modèle secondaire ou une réponse dégradée mais propre, évitent qu’une panne chez votre fournisseur devienne une panne chez vous. Quand les temps de réponse le permettent, le travail de longue durée passe dans des tâches en arrière-plan avec des mises à jour d’état. On ajoute de la mise en cache là où les entrées se répètent, et des délais d’expiration partout.
Rien de tout cela n’est exotique. C’est la même discipline que vous appliquez à n’importe quelle dépendance externe. Les fournisseurs de LLM tombent simplement en panne de façons plus variées que la plupart des API.
Où les humains gardent le contrôle
Prêt pour la production ne veut pas dire entièrement autonome. Pour la plupart des fonctionnalités, la bonne conception garde une personne dans la boucle à des moments précis.
Nous déterminons ces moments avec votre équipe produit. Il peut s’agir d’une file de révision pour les sorties à faible confiance, d’une étape de confirmation avant que la fonctionnalité agisse au nom d’un client, ou d’un interrupteur d’urgence qui permet à la personne de garde de désactiver la fonctionnalité sans déploiement. La suite d’évaluations et la surveillance vous disent où le modèle est fiable. La révision humaine couvre le reste.
Démo ou production
Une façon rapide de savoir où vous en êtes :
| Question | Démo | Production |
|---|---|---|
| Comment savez-vous qu’un changement a aidé? | Quelqu’un a essayé quelques exemples | Le score de la suite d’évaluations a monté |
| Comment repérez-vous les mauvaises réponses? | Un client vous le dit | La surveillance les signale |
| Que se passe-t-il pendant une panne du fournisseur? | La fonctionnalité cesse de fonctionner | La solution de repli prend le relais |
| La sécurité peut-elle approuver? | Pas encore | Oui, documentation à l’appui |
Si votre prototype tombe dans la colonne de gauche pour la plupart de ces questions, c’est normal. C’est aussi exactement le travail que nous faisons.
Votre part
Il nous faut l’accès au dépôt, le prototype lui-même et des exemples de ce qu’est une bonne réponse. Un responsable produit capable d’étiqueter les cas limites et d’approuver la grille d’évaluation accélère les choses. Vos développeurs n’ont pas à mettre la feuille de route sur pause.
Comment se déroule le développement
Vous décrivez la fonctionnalité et l’endroit où elle bloque. Nous définissons la portée du travail avec vous et convenons d’un prix fixe lié aux livrables, avant que quoi que ce soit commence.
Le développement lui-même est réalisé par des agents IA supervisés par des ingénieurs seniors. Ces ingénieurs prennent les décisions d’architecture, révisent chaque changement et s’occupent de l’intégration avec vos systèmes. Le résultat : du code prêt pour la production dans votre dépôt, qui respecte vos conventions, avec une documentation que votre équipe peut maintenir.
La livraison prend de quelques jours à quelques semaines selon la portée. Pas des mois.
Questions fréquentes
Allez-vous réécrire notre prototype de zéro?
En général, non. Si la logique de base fonctionne, nous la gardons et nous construisons autour. Quand quelque chose doit changer pour la production, comme passer d'un appel synchrone à une tâche en arrière-plan, nous vous expliquons pourquoi avant d'y toucher.
Quels outils d'évaluation et d'observabilité utilisez-vous?
Ceux qui conviennent à votre pile technologique. Les cadriciels open source et les plateformes commerciales font tous les deux l'affaire. Si vous payez déjà pour un outil, nous l'utilisons.
Notre équipe pourra-t-elle exécuter la suite d'évaluations après votre départ?
Oui. Elle vit dans votre dépôt et s'exécute dans votre CI. Ajouter un cas de test, c'est aussi simple qu'ajouter une ligne au jeu de données.
Et si nous changeons de fournisseur de modèles plus tard?
C'est justement une des principales raisons d'avoir des évaluations. Vous changez de fournisseur, vous lancez la suite, vous comparez les scores.
