L'IA générative est facile à essayer et difficile à intégrer. Un collaborateur peut obtenir une première réponse en quelques secondes, mais une organisation doit répondre à des questions plus exigeantes : quelles données peuvent être utilisées, qui vérifie le résultat, combien coûte réellement le service et que se passe-t-il lorsqu'il se trompe ?
Le bon point de départ n'est donc pas le choix d'un modèle. C'est un problème précis, fréquent et suffisamment mesurable pour savoir si l'IA apporte un progrès. Ce guide propose une méthode pour passer d'une démonstration séduisante à un service exploitable.
Commencer par une tâche, pas par un assistant universel
Une demande comme « déployer l'IA dans l'entreprise » ne donne aucun critère de réussite. Il faut la ramener à une tâche : résumer un dossier avant une réunion, préparer une réponse de support, retrouver une procédure interne ou proposer une première version de documentation.
Un cas d'usage initial solide possède généralement quatre propriétés :
- il revient assez souvent pour justifier l'effort d'intégration ;
- un humain sait déjà reconnaître une bonne réponse ;
- une erreur reste détectable et récupérable ;
- les données nécessaires sont identifiées.
La fréquence seule ne suffit pas. Automatiser une tâche rare mais très risquée peut coûter plus cher en contrôle que le travail économisé. À l'inverse, une activité répétitive et réversible permet de tester rapidement sans déléguer une décision critique.
Avant tout prototype, écrivez une fiche simple : utilisateur concerné, situation de départ, données utilisées, sortie attendue, décision finale et conséquence d'une erreur. Cette fiche deviendra la base de l'évaluation.
Choisir entre service hébergé, modèle ouvert et développement interne
Un service hébergé réduit le temps de mise en route. Il fournit l'interface, l'infrastructure et les mises à jour, mais impose d'étudier les conditions d'utilisation des données, la localisation, la rétention et les possibilités d'export.
Un modèle à poids ouverts apporte davantage de contrôle sur l'hébergement et la chaîne technique. Il ne supprime ni les coûts ni les dépendances. Il faut assurer l'inférence, les mises à jour, l'observabilité, les évaluations et la sécurité. Notre analyse sur les modèles ouverts et les choix d'intégration détaille ce déplacement de responsabilité.
Le développement interne est pertinent lorsqu'une logique métier différenciante doit être maîtrisée. Il ne signifie pas nécessairement entraîner un modèle. Une architecture interne peut orchestrer un fournisseur externe, une recherche documentaire et des règles de validation tout en conservant le contrôle du produit.
La décision doit comparer le coût complet : abonnement ou jetons, intégration, supervision, tests, support, incidents et possibilité de changer de fournisseur. Le modèle le moins cher par requête n'est pas toujours le système le moins coûteux.
Protéger les données avant le premier usage réel
La première règle consiste à classer les informations avant de rédiger une politique. Données publiques, internes, confidentielles, personnelles ou soumises à un secret métier ne peuvent pas suivre le même chemin.
Pour chaque cas d'usage, documentez :
- les données envoyées au service ;
- leur durée de conservation ;
- leur utilisation éventuelle pour améliorer les modèles ;
- les sous-traitants et régions d'hébergement ;
- les personnes autorisées à consulter les entrées et sorties ;
- la procédure de suppression et d'incident.
Un filtre technique est plus fiable qu'une consigne seule. Les secrets, identifiants, données personnelles ou documents non autorisés doivent être retirés avant l'appel au modèle. Les journaux doivent rester utiles au diagnostic sans recréer une base de données sensible.
Les agents ajoutent un risque supplémentaire : ils peuvent agir. La CNIL souligne notamment les enjeux liés à l'autonomie, à la mémoire persistante et aux interactions avec plusieurs services. Les permissions doivent donc être minimales, temporaires lorsque c'est possible, et séparées entre lecture, proposition et exécution. Le guide sur les agents IA dans les équipes techniques montre pourquoi l'approbation humaine reste une fonction du système.
Mesurer la qualité avec des cas réels
Une impression favorable pendant une démonstration ne constitue pas une évaluation. Construisez un jeu de cas représentatifs à partir du travail réel, puis définissez ce qu'une bonne sortie doit contenir et ce qu'elle ne doit jamais faire.
Les mesures dépendent de la tâche :
- exactitude factuelle et présence des éléments obligatoires ;
- proportion de réponses nécessitant une correction ;
- temps réellement gagné, contrôle compris ;
- taux d'escalade vers un humain ;
- erreurs critiques et faux sentiment de confiance ;
- satisfaction de l'utilisateur final.
La qualité doit être suivie par segment. Une moyenne peut masquer un système performant sur les demandes simples mais dangereux sur les cas rares. Conservez des exemples limites, contradictoires et incomplets dans le jeu de test.
Notre méthode pour évaluer un chatbot avant la production peut servir de base. Relancez ces tests lors d'un changement de modèle, de prompt, de source documentaire ou d'outil connecté.
Calculer le coût au niveau du processus
Le prix d'une requête est facile à mesurer ; le coût du processus l'est moins. Il faut additionner l'inférence, la recherche documentaire, les appels d'outils, le stockage des traces, l'évaluation et le temps humain de vérification.
Suivez au minimum :
- le coût par tâche terminée, pas seulement par message ;
- le volume de contexte envoyé ;
- le nombre de tentatives ou d'appels successifs ;
- le temps de contrôle humain ;
- le coût des erreurs et reprises ;
- le taux de tâches abandonnées.
Une réponse plus courte et plus structurée peut être plus rentable qu'un modèle moins cher qui nécessite plusieurs corrections. Fixez aussi un plafond par utilisateur, équipe ou processus afin qu'une boucle d'agent ne transforme pas un incident fonctionnel en incident financier.
Installer une gouvernance légère mais réelle
La gouvernance n'a pas besoin de commencer par un comité complexe. Elle doit d'abord rendre les responsabilités visibles. Pour chaque système, désignez :
- un propriétaire métier responsable du besoin ;
- un propriétaire technique responsable du fonctionnement ;
- une personne ou fonction responsable des données et risques ;
- un canal de signalement des erreurs ;
- une date de revue.
Tenez un registre des usages IA, même simple. Il doit indiquer le fournisseur, le cas d'usage, les données, les utilisateurs, les contrôles et la décision de poursuivre ou d'arrêter. Le cadre du NIST propose quatre fonctions utiles pour structurer ce travail : gouverner, cartographier, mesurer et gérer.
L'AI Act européen ajoute des obligations variables selon le rôle de l'organisation et le niveau de risque du système. Une classification juridique ne doit pas être improvisée à partir d'une liste générique : le contexte, la finalité et les personnes affectées comptent. Le registre permet au moins de savoir quels systèmes doivent être examinés.
Un plan de déploiement en quatre étapes
1. Cadrer
Choisissez une tâche, un groupe limité d'utilisateurs et trois mesures de réussite. Classez les données et décrivez les erreurs inacceptables.
2. Tester
Construisez un jeu d'évaluation avant de personnaliser longuement le système. Comparez au processus actuel, pas à une démonstration idéale.
3. Piloter
Ouvrez l'usage à un périmètre contrôlé. Enregistrez coûts, corrections, incidents et retours. Donnez aux utilisateurs un moyen simple de contester ou d'escalader une sortie.
4. Industrialiser ou arrêter
Automatisez les contrôles, formalisez le support et préparez une solution de repli. Si le gain disparaît une fois le contrôle inclus, arrêtez ou réduisez le périmètre. Un pilote qui conclut « non » évite parfois l'investissement le plus coûteux.
La décision utile
Une stratégie IA mature ne cherche pas à placer un assistant partout. Elle sélectionne les tâches où une sortie probabiliste peut être contrôlée, corrigée et mesurée. La valeur vient ensuite de l'intégration dans le travail réel : données autorisées, outils adaptés, responsabilité claire et retour possible vers un humain.
Le premier livrable ne devrait pas être un chatbot. Il devrait être une fiche de cas d'usage, un jeu de tests et une décision explicite sur les données. Ces trois éléments restent utiles quel que soit le modèle finalement choisi.
