La démo fonctionnait. La production est une autre conversation.
Un PoC d’IA démontre que l’idée est possible. Il ne démontre pas qu’elle tient face aux données du client, à ses permissions, à son volume ni à sa revue de sécurité. Voici la liste de ce qui manque le plus souvent, écrite pour que vous puissiez l’utiliser comme checklist même si vous ne nous appelez pas.
Si le projet est celui d’un de vos clients, voyez comment nous travaillons avec les cabinets de conseilCe qui manque presque toujours
- 01
Il n’y a aucun moyen de savoir s’il répond bien
Sans évaluations automatisées, la qualité se juge en essayant à la main et en se souvenant. Chaque changement de prompt, de modèle ou de données est un pari. Il faut des cas de test avec réponse attendue, exécutés à chaque changement, et un seuil en dessous duquel on ne déploie pas.
- 02
Personne ne peut expliquer une réponse précise
Quand le client demande pourquoi l’agent a dit quelque chose, il faut pouvoir le reconstruire : ce qui a été récupéré, avec quelles permissions, quel prompt a été envoyé, quelle version de modèle a répondu. Sans cette trace, pas d’audit possible ni de moyen de corriger la cause.
- 03
Les permissions du PoC ne sont pas celles du client
Un prototype lit en général tout le corpus. En production, deux utilisateurs différents doivent voir des choses différentes, et le filtrage doit se faire à la récupération, pas dans le prompt. C’est le point où le plus de projets se bloquent dans la revue de sécurité.
- 04
Il n’y a de plafond ni de dépense ni de latence
Le coût par tâche et le temps de réponse ne se mesurent pas tant que quelqu’un ne les paie pas ou ne les subit pas. Il faut des limites, des alertes et une décision explicite sur ce qui se dégrade quand elles sont atteintes.
- 05
On ne peut pas revenir en arrière
Si le déploiement n’est pas reproductible et qu’il n’y a pas de rollback, chaque changement est irréversible en pratique. Infrastructure décrite en code sur Azure, environnements séparés et un chemin de retour éprouvé.
- 06
Il se trompe tout seul, sans filet
Là où se tromper coûte de l’argent ou de la réputation, la décision est approuvée par une personne. Définir où se trouve cette frontière est une décision métier, pas technique, et il vaut mieux la prendre avant d’ouvrir le système.
Emportez-la et servez-vous-en même si vous ne nous appelez pas : la version imprimée reprend les six points avec de la place pour noter lesquels vous avez résolus.
Ce que votre client va demander avant de nous laisser entrer.
Quand le projet est celui d’un client final, quelqu’un de son équipe de sécurité va examiner cela. Nous l’avons par écrit avant de commencer, pour que vous puissiez le montrer au lieu de l’improviser.
-
Accès minimaux et environnements convenus
Nous travaillons avec juste les permissions nécessaires à la pièce qui nous revient et dans les environnements convenus. Pas d’identifiants partagés ni d’accès ouverts « pour aller plus vite ».
-
Les permissions du client s’appliquent à la récupération
Deux utilisateurs différents voient des choses différentes, et le filtrage se fait au moment de récupérer les données, pas en faisant confiance au prompt. C’est le point où le plus de projets se bloquent dans la revue de sécurité.
-
Chaque réponse peut être reconstruite
Ce qui a été récupéré, avec quelles permissions, quel prompt a été envoyé et quelle version de modèle a répondu. Sans cette trace, pas d’audit possible ni de moyen de corriger la cause.
-
Quelles données touchent les outils d’IA, par écrit
Si des modèles de tiers interviennent, nous définissons à l’avance quelles données peuvent être utilisées, où et dans quelles limites, dans un format que vous pouvez transmettre à la sécurité de votre client.
-
Guardrails et contrôle humain là où ça coûte de l’argent
Des limites de coût et de latence avec alertes, et une frontière explicite : où l’agent décide seul et où une personne approuve. Cette frontière est une décision métier et elle se prend avant d’ouvrir le système.
-
Confidentialité et non-circumvention signées
NDA avant de nous raconter le détail si vous en avez besoin, et non-circumvention par écrit : nous ne vendons rien à votre client pour notre compte, ni pendant le projet ni après.
-
Le code est le vôtre dès le premier jour
Il vit dans les dépôts que vous indiquez, pas dans les nôtres. À la clôture restent les runbooks, le rapport d’évaluations et les sessions de transfert : vous ne dépendez pas de nous pour exploiter ce qui a été livré.
Si votre client exige une homologation précise ou un partenaire officiel donné, dites-le nous dès le premier appel : mieux vaut le savoir à ce moment-là qu’en cours de projet.
Comment nous l’abordons
Nous ne partons pas de zéro. Nous examinons ce qui existe, nous disons ce qui est conservé et ce qui est réécrit, et nous fermons le périmètre par jalons avec des critères d’acceptation écrits avant de commencer. Si l’approche de base ne tient pas, nous le disons avant de signer et pas en cours de projet.
Racontez-nous ce qui est construit, avec quelles données et pour quand cela doit être en production. En 30 minutes nous vous rendons une carte des risques et un avis clair sur ce qui manque.
Trois livraisons, avec contexte et résultatOn parle de votre projet ?
En 30 minutes nous passons en revue ce que vous voulez construire ou ce que vous avez déjà en cours, les données, les intégrations et ce qui manque pour que ça tienne quand les utilisateurs arriveront. Peu importe que le projet soit le vôtre ou celui d’un de vos clients : l’appel est le même.
Revue gratuite de 30 min, sans engagement. Nous signons un NDA au préalable si vous en avez besoin. Nous répondons le jour ouvré suivant.