1. Choisir une tâche que vous pouvez évaluer
Cherchez une activité répétitive avec des entrées reconnaissables et une sortie vérifiable : classer des demandes, préparer un brouillon de réponse ou extraire des champs de documents. Écartez pour un premier pilote les processus où une erreur peut déclencher des paiements, des engagements commerciaux ou des décisions difficiles à annuler. La première version doit permettre d’apprendre sans transférer toute la responsabilité au système.
Décrivez le processus actuel : entrée, responsable, sortie et exceptions. Si une règle simple résout la tâche de façon fiable, l’IA n’est peut-être pas nécessaire. Réservez le modèle à l’interprétation du langage ou des documents et gardez des règles explicites pour les dates, montants, droits et états. Il sera plus facile de comprendre une erreur et de la corriger.
2. Convenir des données, limites et responsabilités
L’AI Risk Management Framework du NIST est un cadre volontaire pour gérer les risques de l’IA pendant la conception, l’utilisation et l’évaluation. Pour un pilote, sa traduction pratique est simple : documenter l’objectif, les responsables, les limites et les critères de revue. [1]
Cartographiez les données entrantes, leur lieu de traitement, les personnes pouvant y accéder et leur durée de conservation. Commencez avec des exemples synthétiques ou préparés pour les tests, sans secrets ni données personnelles inutiles. Vérifiez les conditions du fournisseur pour votre compte et votre contrat précis ; ne supposez pas que tous les produits traitent les données de la même façon.
3. Concevoir un flux avec une issue sûre
Exemple hypothétique : des demandes de support arrivent par courriel. L’IA propose une catégorie et un brouillon ; une personne vérifie les deux et décide de l’envoi. Le système enregistre la proposition, les corrections et le temps passé. À ce stade, il ne supprime pas de courriels, ne modifie pas de contrats et n’écrit pas directement dans les données de production. La revue humaine est une étape définie du processus.
Précisez ce qui se passe lorsque des informations manquent, qu’un format est inattendu ou qu’une demande sort du périmètre. Une sortie utile peut être « à vérifier », avec une raison. Évitez de forcer le modèle à donner une réponse définitive dans tous les cas. Les règles d’acceptation doivent être appliquées dans le code ou l’application qui exécute le flux, sans dépendre uniquement des réponses du modèle.
4. Traiter les documents comme des données
OWASP décrit l’injection indirecte d’instructions comme un risque lorsque du contenu externe, par exemple un fichier ou un site, modifie le comportement d’un modèle. La récupération de documents avec le RAG ne supprime pas ce risque à elle seule. [2]
Séparez donc les actions autorisées au système du contenu qu’il trouve dans un courriel. Accordez aux intégrations uniquement les droits nécessaires et gardez les identifiants hors du contenu transmis au modèle. Si le pilote prépare seulement des brouillons, il n’a pas besoin du droit de les envoyer. Faites confirmer les actions ayant des conséquences par une personne et consignez son approbation.
5. Mesurer avec des exemples représentatifs
Préparez des cas courants et des exceptions avant de commencer. Incluez des informations incomplètes, doublons, ambiguïtés et langues réellement utilisées. Gardez une réponse attendue ou un critère d’évaluation pour chaque cas. Séparez les exemples servant à ajuster le flux de ceux utilisés pour l’évaluer, afin de ne pas confondre adaptation et qualité générale.
Mesurez le temps total, revue comprise, les erreurs acceptées, les corrections et le coût par tâche. Comparez avec le processus antérieur sur des cas équivalents. Un brouillon rapide peut ne rien faire gagner si sa vérification demande plus de temps que sa rédaction. Définissez à l’avance la qualité acceptable et qui décide de poursuivre, ajuster ou arrêter ; ne promettez aucun pourcentage de gain sans mesure.
6. Étendre uniquement ce qui a été vérifié
Commencez avec quelques personnes et un volume limité. Documentez comment arrêter le flux, revenir au processus manuel et examiner les travaux en attente sans les exécuter deux fois. Un changement de modèle, d’instructions ou d’intégration peut modifier les résultats : conservez les versions et effectuez une évaluation proportionnée avant d’élargir les droits ou le volume.
Pour des équipes à Barcelone ou réparties dans plusieurs pays, testez chaque langue réellement utilisée et convenez des horaires de support interne. Le pilote doit produire une décision étayée : poursuivre, modifier le périmètre ou abandonner l’idée. Une automatisation utile est celle que l’équipe peut superviser, maintenir et expliquer après la démonstration initiale.