Le pilote a fonctionné. Les équipes veulent continuer à l’utiliser. La décision suivante consiste à déterminer si l’organisation peut exploiter tout le processus lorsque les personnes ayant construit la démonstration reprennent d’autres missions.
Un système d’IA change davantage que la vitesse d’une tâche. Il ajoute une dépendance à un modèle, des mouvements de données et un chemin par lequel une suggestion incorrecte peut devenir une action. Chaque partie demande quelqu’un ayant les moyens et l’autorité pour intervenir.
La responsabilité devient visible lorsqu’un résultat plausible est faux, qu’un fournisseur modifie son comportement ou que la seule personne connaissant l’intégration est absente. Préparez ces situations avant de considérer le pilote comme un service en exploitation.
Attribuer la responsabilité au processus
Nommez une personne responsable du résultat métier attendu. Elle accepte les limites et décide si le bénéfice justifie la poursuite de l’exploitation. Nommez une responsabilité de service pour les dépendances, la surveillance, les versions et la restauration au quotidien.
Dans une petite organisation, une personne peut cumuler plusieurs rôles. Les responsabilités restent explicites et une suppléance doit pouvoir agir. Un prestataire peut exploiter une composante pendant qu’une personne en interne reste responsable de l’usage qu’en fait l’organisation.
Le cadre de gestion des risques de l’IA du NIST prévoit des responsabilités définies, une surveillance continue et un retrait sûr du service. La carte suivante traduit ces préoccupations en questions utilisables lors d’une passation.
Garder une carte des responsabilités avec le service
| Responsabilité | Décision à attribuer | Preuve à conserver |
|---|---|---|
| Résultat métier | Continuer, restreindre ou arrêter l’usage | Résultat attendu, limites et risques résiduels acceptés |
| Exploitation | Mettre en service, suspendre et restaurer le processus | Procédure, suppléance, historique des versions et secours testé |
| Usage des données | Autoriser les entrées, la conservation et les traitements tiers | Flux de données et limites d’usage approuvées |
| Revue des résultats | Accepter, corriger ou rejeter les résultats à conséquences | Critères de revue, escalade et échantillons de résultats |
| Dépendance au fournisseur | Accepter un changement de modèle ou de prestataire | Versions, cas d’évaluation et procédure de sortie |
| Réponse aux incidents | Contenir le problème et autoriser la reprise | Journal des décisions, inventaire des tâches touchées et preuves de restauration |
Inscrivez les noms réels et les suppléances dans la copie privée de l’organisation. Coordonnées et identifiants n’ont pas leur place dans la documentation publique. Un rôle dans un schéma n’est utile que si la personne dispose du temps, des accès et de l’autorité nécessaires.
Définir ce que le système peut faire
Décrivez l’unité de travail : résumer un document, préparer un projet d’offre, classer une demande de support ou proposer un changement de rendez-vous. Précisez les actions soumises à approbation et ce que la personne qui approuve doit voir. L’approbation lie destinataire, contenu et action prévue, afin qu’une modification demande une nouvelle décision.
Distinguez préparation et exécution. Si un outil signale une livraison incertaine, l’équipe doit pouvoir examiner l’opération existante chez le fournisseur avant de réessayer. Répéter l’instruction peut dupliquer un message, un paiement ou une publication. Ce chemin de clarification fait partie du service ; il ne devrait pas être improvisé à la découverte du problème.
Surveiller le résultat dont les personnes dépendent
Conservez un petit ensemble d’évaluation représentatif de la tâche réelle, avec des cas difficiles et des cas que le système doit refuser. Notez modèle, instructions, sources consultées et configuration pertinente pour chaque version. Répétez les contrôles lorsque ces éléments changent.
En exploitation, examinez un échantillon proportionné des tâches terminées. Consignez corrections, interventions humaines, réclamations et erreurs non résolues. Le succès technique est une preuve incomplète : une requête réussie peut joindre le mauvais document ou produire une réponse inutilisable. La responsabilité métier définit le résultat acceptable.
Reliez chaque condition surveillée à une action. Qui reçoit le signal, quand faut-il suspendre le processus et quelles preuves permettent de reprendre ? Une alerte sans personne chargée de la traiter devient une autre dépendance laissée sans surveillance.
Exercer l’escalade et le secours
Utilisez un cas synthétique dans un environnement contrôlé. Rendez une entrée obligatoire indisponible, faites retourner une réponse incorrecte par un fournisseur simulé ou interrompez le worker après une action externe peut-être déjà exécutée. La suppléance doit retrouver les tâches concernées et suivre la procédure de récupération.
Le secours peut offrir moins que le service normal. Une équipe peut temporairement vérifier chaque résultat, placer le travail en attente ou arrêter une catégorie d’actions. Définissez ce fonctionnement réduit à l’avance, avec sa capacité et les limites au-delà desquelles poursuivre devient inacceptable.
Consignez les étapes seulement décrites. Une explication orale sur la révocation d’une clé ou la clarification d’une livraison ne démontre pas que les accès nécessaires sont disponibles.
Inclure la sortie dans l’accord d’exploitation
La responsabilité de service doit savoir arrêter le nouveau travail, rendre compte des opérations en cours, exporter les enregistrements nécessaires et retirer les accès devenus inutiles. Vérifiez les obligations de conservation et les engagements clients qui subsistent après un changement de modèle ou de fournisseur.
Testez une tâche représentative avec le remplacement envisagé avant de basculer. Conservez les anciens résultats d’évaluation et configurations pour pouvoir examiner un changement de comportement. Les économies doivent être appréciées avec l’effort de revue, le traitement des erreurs et la maintenance du remplacement.
Avant la passation, faites convenir les responsabilités métier et de service du périmètre, des suppléances, du rythme de revue, des limites d’escalade et des ressources. Réexaminez cet accord lorsque l’usage ou le fournisseur change. Un pilote devient un service exploitable lorsque l’organisation peut tenir ces engagements dans la durée.
À lire avec Pourquoi les projets d’IA échouent, Une stratégie d’IA sans responsabilité opérationnelle est du théâtre et Le piège de l’optimisation. Ces textes examinent différents moments où un résultat technique prometteur perd son lien avec l’organisation responsable de son usage.