9 min de lecture - Passation de consultant IA : maintenir le système en marche

Les consultants partent souvent juste après un « lancement réussi ».

Puis, une semaine plus tard :

• la qualité des sorties dérive
• une intégration tombe en panne
• personne ne sait quel prompt a changé
• la sécurité demande où vont les données

Ce n'est pas un problème de modèle.

C'est un problème de passation.

Si vous voulez un plan de passation qui maintienne réellement les systèmes en fonctionnement, une simple pile de documents ne suffit pas. Il vous faut un véritable transfert de responsabilité : des procédures d'exploitation, des ressources d'évaluation, un processus de gestion des changements et une équipe formée pour piloter le workflow. Cela vaut aussi bien lorsque vous achevez une mission de conseil que lorsque vous reprenez un système en cours de route.

Ce que vous allez apprendre

• Le socle minimal d'un dossier de passation pour les systèmes d'IA
• Comment transférer l'évaluation, pas seulement le code
• Les contrôles de préparation opérationnelle qui évitent une réécriture
• Des modèles de gouvernance et de responsabilité qui fonctionnent
• Une checklist de passation réutilisable

L'essentiel

Les systèmes d'IA se dégradent après le départ du consultant lorsque la responsabilité et l'évaluation n'ont pas été transférées. Une passation solide comprend une vue d'ensemble de l'architecture, un périmètre des données, des procédures d'exploitation, un journal des changements et un dispositif d'évaluation assorti d'un calendrier. Évaluez la préparation opérationnelle (incidents, retour arrière, supervision) et formez les responsables internes. La passation est un modèle opérationnel, pas un simple PDF.

Plan de passation d'un consultant IA : ce qui doit être transmis

Transférez au minimum cinq éléments.

1. Architecture et périmètre des données
2. Contrôle des changements
3. Évaluation et supervision
4. Runbooks et réponse aux incidents
5. Responsabilité et formation

Si l'un de ces éléments manque, le système reste dépendant du consultant.

Le dossier de passation (ce qu'il faut mettre dans le dossier)

Restez concis et utile.

1) Vue d'ensemble de l'architecture (1 à 2 pages)

• ce que fait le workflow
• les systèmes concernés
• où circulent les données
• où se fait la journalisation

2) Périmètre des données et notes d'accès

• sources autorisées
• sources restreintes
• qui a accès à quoi
• comment les identifiants sont gérés — consultez notre guide des clauses de cybersécurité pour les protections à intégrer au contrat

3) Journal des changements et journal des décisions

• ce qui a changé
• quand cela a changé
• pourquoi cela a changé
• qui l'a approuvé

C'est ce qui distingue la gouvernance de l'approximation.

4) Jeu d'évaluation et mode d'exécution

• un petit jeu de test (exemples réels)
• la grille de notation
• quand le relancer (chaque semaine, après chaque changement)

5) Runbook

• comment déboguer
• comment faire un rollback
• comment escalader
• comment faire une rotation des secrets

Revue de préparation opérationnelle (l'étape que les équipes sautent)

Avant le départ, menez une revue de préparation.

Checklist :

• Pouvons-nous déployer sans le consultant ?
• Les logs sont-ils exploitables et sûrs ?
• Le chemin de rollback fonctionne-t-il ?
• Pouvons-nous effectuer une rotation des identifiants ?
• Pouvons-nous reproduire les résultats d'évaluation ?

Faites un exercice d'incident. Même un exercice de 30 minutes suffit à révéler des failles.

Si vous avez hérité d'un système d'IA avec une passation bâclée

Parfois, vous ne planifiez pas un départ. Vous subissez les conséquences d'un départ déjà survenu.

Si le système a été livré sans passation en bonne et due forme, voici le moyen le plus rapide de le stabiliser sans tout réécrire :

1. Rédigez une « procédure d'exploitation minimale » d'une seule traite. Même si elle n'est pas élégante. Notez où le système fonctionne, comment il est déployé, où se trouvent les journaux, comment revenir à la version précédente, qui dispose des accès et comment les identifiants sont mis à jour.
2. Prenez un instantané du comportement actuel. Constituez un petit jeu d'évaluation à partir d'entrées réelles (20 à 30 exemples) et conservez les sorties comme référence de départ. On ne peut pas améliorer ce qu'on ne peut pas comparer.
3. Gelez les changements non maîtrisés. Faites passer tous les changements par un point d'entrée unique et un seul responsable. L'objectif est d'arrêter la spirale du « personne ne sait ce qui a changé ».
4. Rendez le périmètre des données explicite. Listez les sources autorisées et les sources interdites. En cas de doute, appliquez des règles restrictives et assouplissez-les plus tard.
5. Menez un exercice d'incident de 30 minutes. Choisissez un scénario de panne réaliste (mauvaises sorties, interruption de service, bug de permissions) et vérifiez si l'équipe peut réagir sans tâtonner.

Cette séquence transforme rapidement un « système mystère » en « système opérable », ce qui vous donne le temps de prendre de meilleures décisions d'architecture par la suite.

Transfert de responsabilité (rendez-le explicite)

Désignez un responsable unique et redevable.

Documentez ensuite :

• la responsabilité de la liste des tâches
• la responsabilité des incidents
• les changements d'accès et de permissions
• les changements de fournisseur ou de modèle

Engagez-vous sur un rythme — un SLA de maintenance bien conçu rend cela concret :

• un tri hebdomadaire
• un rapport mensuel
• une revue trimestrielle des résultats et des coûts

Critères d'acceptation de la passation (pour que « terminé » ne soit pas subjectif)

Pour que la passation soit réelle, définissez des critères d'acceptation. Par exemple, le responsable interne doit pouvoir réaliser ces tâches sans le consultant :

• Déployer sur l'environnement cible (ou expliquer le processus de déploiement étape par étape)
• Relancer la suite d'évaluation et interpréter les résultats
• Faire une rotation d'un identifiant en toute sécurité
• Effectuer un rollback d'un changement (prompt/configuration/code) et confirmer que le comportement est rétabli
• Expliquer le périmètre des données et la politique de journalisation à un auditeur sécurité

Quand ces conditions sont réunies, le départ est sûr. Quand elles ne le sont pas, vous ne partez pas : vous transférez un risque.

Inscrivez le départ dans le contrat (pour qu'il ait vraiment lieu)

Si vous êtes le client : traitez la passation comme un livrable, pas comme une option agréable à avoir. Intégrez un jalon de sortie explicite dans le cahier des charges (SOW), avec des critères d'acceptation (runbook, dispositif d'évaluation, exercice d'incident, transfert des accès).

Si vous êtes le consultant : cela vous protège également. Des critères de sortie clairs évitent les interminables « petites questions » et fixent les attentes sur ce qui se passe après la mission.

Sessions de transfert de connaissances (pour que ce soit concret)

La documentation ne transmet pas l'intuition.

Pour que l'équipe interne s'approprie réellement le système, planifiez au moins deux sessions en direct avant le départ :

• Présentation de l'architecture : périmètre des données, intégrations et journal des décisions
• Exercice opérationnel : reproduire une exécution d'évaluation, déclencher un rollback et faire une rotation d'un identifiant

Enregistrez les sessions et conservez les liens à côté du runbook. L'objectif n'est pas un exposé parfait. L'objectif est de s'assurer que quelqu'un d'autre puisse faire le travail un jour de crise.

Un schéma simple et efficace consiste en une courte semaine de doublure :

• Semaine 1 : le consultant pilote, le responsable interne observe et pose des questions
• Semaine 2 : le responsable interne pilote, le consultant observe et n'intervient qu'en cas de nécessité

C'est souvent le moyen le plus rapide d'éviter que la « passation » ne se transforme en une lente réécriture.

L'agenda de la dernière semaine (un planning que l'on suit vraiment)

Si vous laissez la « passation » au dernier jour, elle se résume à un appel précipité et une pile de liens.

Une meilleure approche consiste à planifier la dernière semaine comme un mini-projet :

• Jour 1 : présentation de l'architecture (périmètre des données, intégrations, emplacement des prompts et de la configuration)
• Jour 2 : session « faire tourner en local » (comment reproduire le comportement, comment lancer l'évaluation)
• Jour 3 : exercice de déploiement et de rollback (livrer un petit changement puis le rollback délibérément)
• Jour 4 : revue sécurité/ops (journalisation, rétention, accès, rotation des identifiants)
• Jour 5 : validation de la responsabilité (qui gère les incidents, le backlog, les changements de fournisseur ou de modèle)

Cela peut sembler beaucoup, mais chaque session peut tenir en 45 minutes. L'avantage est que le responsable interne manipule le système sous plusieurs angles avant que le consultant ne disparaisse.

Le modèle de checklist de passation

Liste de contrôle de la passation

Documentation :
- Vue d'ensemble de l'architecture
- Périmètre des données et accès
- Procédures d'exploitation
- Journal des changements

Qualité :
- Jeu d'évaluation
- Grille de notation
- Calendrier et responsable

Exploitation :
- Supervision et alertes
- Retour arrière testé
- Exercice de gestion d'incident réalisé

Responsabilités :
- Responsable désigné
- Rythme de suivi convenu
- Formation achevée

Où stocker la passation (pour qu'elle ne disparaisse pas)

La passation échoue quand les artefacts existent, mais que personne ne parvient à les retrouver sous pression.

Une règle de stockage simple :

• Placez les éléments opérationnels près du code : runbooks, instructions d'évaluation, étapes de rollback et notes de configuration dans le dépôt.
• Placez le contexte des décisions dans un espace accessible à la direction : le journal des décisions et les notes de gouvernance dans un espace documentaire partagé.
• Mettez des liens partout : le runbook doit renvoyer vers la suite d'évaluation, les tableaux de bord et le processus de gestion des incidents.

Vous concevez pour le pire moment : le premier incident après le départ du consultant.

Transférez la responsabilité, pas seulement le code

Une vraie passation transfère la responsabilité, pas seulement le code. Si vous gardez l'évaluation, les runbooks et le contrôle des changements au sein de l'équipe, le système reste stable après le départ du consultant. Besoin d'aide pour concevoir une passation qui tient dans la durée ? Parlons-en.