Chapeau. Un bac à sable montre qu’une tâche peut fonctionner dans des conditions choisies. L’exploitation doit rendre le workflow répétable lorsque données, utilisateurs, fournisseurs, erreurs et obligations changent. L’écart relève de la gouvernance et de l’ingénierie, pas seulement du réglage du modèle.
Ce que démontre un prototype
Il peut vérifier qu’un modèle produit un résultat utile à partir d’entrées préparées, révéler des défaillances et préciser le besoin. Il n’établit ni fiabilité en production, ni licéité, ni intégration sûre, ni supportabilité, ni coût total acceptable.
L’affirmation « 20 % de l’effort » du calendrier doit rester une illustration rhétorique, non un ratio universel mesuré. La part varie selon le workflow et les capacités existantes.
Ce qu’ajoute l’exploitation
- Service défini : finalité, utilisateurs, entrées, exclusions, propriétaire.
- Information : classification, provenance, droits, conservation, effacement.
- Architecture : identité, intégrations, réseau, clés, logs, résilience, sortie.
- Assurance : tests représentatifs, seuils, scénarios adverses, revue proportionnée.
- Contrôle humain : portes, preuves, exceptions et séparation brouillon/action.
- Exploitation : suivi, incidents, support, changements, retour arrière et retrait.
- Économie : licences, intégration, revue, exceptions, assurance et changements.
Porte de mise en production
| Question | Preuve requise |
|---|---|
| Le résultat est-il utile ? | Référence initiale et test d’acceptation |
| L’usage est-il autorisé ? | Revues métier, juridique et données enregistrées |
| Les accès sont-ils maîtrisés ? | Tests par rôle et tests négatifs |
| Les défaillances sont-elles bornées ? | Scénarios, seuils, mécanisme d’arrêt |
| Le service est-il supportable ? | Propriétaire, runbook, suivi, incident |
| Peut-il évoluer sûrement ? | Versions, régression, retour arrière |
| Peut-il être retiré ? | Export, effacement, plan de retrait |
Le NIST présente la gestion du risque comme continue entre gouverner, cartographier, mesurer et gérer. La FINMA souligne également cycle de vie, inventaire, tests et surveillance dans son champ. Une démo ne couvre qu’une partie de ce travail.
Erreurs de transition
Identifiants de prototype conservés, compte personnel du développeur, tests limités aux cas idéaux, temps de validation omis du coût, exécution connectée avant compréhension des exceptions : ces choix rendent le pilote fragile. Un « pilote » indéfini est également risqué lorsque de vrais utilisateurs en dépendent sans responsabilité durable.
Interprétation de Cytria
L’expérimentation demande « cela pourrait-il aider ? ». L’exploitation demande « qui répond de quoi, dans quelles conditions, avec quelles preuves, et que se passe-t-il lors d’un échec ou d’un changement ? ». La transition est achevée lorsque la seconde réponse est maintenue.