Playbook 4 — Déploiement et cycle de vie
Déploiement par paliers — du pilote à la production, jusqu'à la mise hors service
Pourquoi encadrer le déploiement par paliers
Un système d’IA qui fonctionne en test peut encore se comporter différemment une fois confronté à de vrais utilisateurs et à de vraies données. La solution n’est pas de tester davantage en amont — c’est un déploiement progressif et contrôlé, avec une sortie définie à chaque étape. Ce playbook se déroule en parallèle de votre plan d’adoption (préparation, sélection des cas d’usage, jalons d’adoption) ; c’est le jalon technique et de risque, pas celui de la conduite du changement.
Les quatre paliers
Quatre points où le déploiement doit mériter le droit de continuer. Le reste de cette page détaille chacun.
| Palier | Ce qui doit être vrai pour franchir | Qui valide |
|---|---|---|
| 1. Pilote contrôlé | Limité au personnel ou à un petit segment ; déclencheur de retour arrière défini ; un humain peut annuler toute décision individuelle | Relecteur métier/opérations (playbook 5) |
| 2. Mise en service / production | Liste de contrôle du pilote validée ; plan de surveillance en place ; contrôle des biais du playbook 3 réussi | Responsable IA |
| 3. Production continue | Plan de surveillance en cours ; aucun signal de réentraînement ou de retrait déclenché | Responsable IA, revue trimestrielle |
| 4. Retrait | Liste de contrôle de retrait complète ; solution de remplacement ou de repli en place avant l’arrêt | Responsable IA, consigné au playbook 6 |
Avant le pilote : exigences et vérification
La liste de contrôle du pilote ci-dessous suppose que deux choses ont déjà eu lieu. Sautez-les et le pilote vous dira si le système fonctionne — pas s’il fonctionne pour la raison que vous croyez.
- Un paragraphe, écrit noir sur blanc : pourquoi ce système, ce qu’il doit faire, et quelles données l’entraînent ou l’alimentent.
- Un plan de test existe — à quoi ressemble un « succès », testé sur des données qui ressemblent réellement à ce que la production verra, pas un jeu de démonstration propre.
- Vous vous êtes mis d’accord à l’avance sur les raisons acceptables pour lesquelles le système pourrait manquer sa cible (un taux d’erreur sous 5 % pour une première version, par exemple) — pas un seuil réussite/échec fixé après avoir vu les résultats.
Liste de contrôle du pilote contrôlé
- Limité au personnel interne, ou à un segment de clients petit et défini — pas tout le monde dès le premier jour.
- Il existe un déclencheur de retour arrière clair : un taux d’erreur, un volume de plaintes ou un résultat précis qui met le déploiement en pause automatiquement.
- Un humain peut relire ou annuler toute décision individuelle que le système prend pendant le pilote.
- Quelqu’un regarde réellement les sorties chaque semaine, au lieu de faire confiance au tableau de bord.
Plan de surveillance — quoi suivre après la mise en service
- L’exactitude ou la qualité des sorties — vérifier un échantillon chaque mois.
- Le taux d’erreur ou le volume de plaintes, et s’ils sont à la hausse.
- Si le système se comporte toujours de façon cohérente entre les groupes contrôlés au playbook 3.
- Si les données sous-jacentes ou les conditions de l’activité ont assez changé pour justifier une nouvelle vérification (nouvelle gamme, nouveau marché, nouvelle réglementation).
Tenez un journal continu des événements du système, pas seulement des vérifications mensuelles. Pour la plupart des outils en PME, c’est le journal d’activité du fournisseur — vérifiez qu’il existe, et que quelqu’un peut le sortir si une décision est un jour contestée. La vérification ponctuelle vous dit qu’il fonctionne encore ; le journal est ce que vous remettez à qui vous demande pourquoi il a fait quelque chose de précis.
Signes qu’il est temps de réentraîner ou de retirer
- Le taux d’erreur ou les plaintes ont nettement augmenté depuis le lancement.
- Il ne reflète plus la réalité actuelle de l’activité (nouveau modèle de tarification, nouvelle clientèle, nouvelle réglementation).
- Une alternative meilleure ou moins chère existe désormais.
- On le maintient en vie par habitude plutôt parce qu’il apporte encore de la valeur.
Si le système continue d’apprendre
La plupart des outils d’IA en PME sont figés entre les mises à jour — c’est le fournisseur qui le réentraîne, pas vous. Si le vôtre fait exception (un modèle qui se met à jour sur vos données, ou une fonction qui s’adapte au comportement des utilisateurs en temps réel), la liste de contrôle de réentraînement/retrait ci-dessus ne suffit pas à elle seule. Ajoutez un contrôle permanent :
- Quelqu’un repasse les données de test d’origine dans le système selon un calendrier fixe — mensuel, pour la plupart des usages en PME — pas seulement quand quelque chose semble anormal.
- Une dérive de la sortie est traitée comme un déclencheur au même titre qu’un pic de taux d’erreur, pas comme quelque chose qu’on attend de remarquer.
Si rien dans votre système n’apprend en continu, sautez cette section. La plupart des déploiements en PME peuvent.
Liste de contrôle du retrait
- La raison du retrait est documentée.
- Quiconque ou quoi que ce soit qui dépend de ce système dispose d’une solution de remplacement ou de repli avant l’arrêt.
- Les enregistrements historiques et les journaux de décision sont conservés, pas supprimés, aussi longtemps qu’ils peuvent compter (audits, litiges).
- L’inventaire des systèmes d’IA (playbook 6) est mis à jour pour refléter le retrait.
Étapes suivantes
Mettez à jour l’inventaire des systèmes d’IA et le journal des décisions (playbook 6) à chaque palier — c’est ce qui transforme « nous avons été prudents » en quelque chose que vous pouvez réellement montrer à quelqu’un.