Cent jours pour installer une capacité, pas pour tout automatiser

Ce guide présente un scénario illustratif. Les personnes, volumes et règles de décision servent à expliquer une méthode ; ils ne décrivent pas une mission ou un résultat client de CYTIZEN. Sophie, directrice de programme, reçoit une demande : transformer plusieurs expérimentations d’IA en services utilisables. Elle refuse de promettre que tous les usages seront industrialisés en cent jours. Elle propose de disposer, au jour cent, d’un modèle d’exploitation vérifiable et d’au moins un parcours dont la poursuite, la limitation ou l’arrêt aura été décidé sur preuves.

Le modèle d’exploitation rassemble le propriétaire métier, les responsables techniques, la gestion des données, les contrôles, le support et le financement. Il ne se résume pas à un comité IA ou à un catalogue d’outils. Sophie retient pour l’exercice un assistant de recherche documentaire : il répond avec des sources autorisées, ne valide aucun document et ne peut exécuter une action dans un autre système. Ce périmètre permet de tester l’exploitation avant d’introduire des agents dotés de droits d’action.

Jours 1 à 15 : nommer le service et son mandat

La première séquence produit une fiche de service remplie. Finalité : retrouver une instruction approuvée. Population : collaborateurs habilités sur un site pilote. Données : corpus documentaire désigné. Sortie attendue : réponse avec source, version et date. Limites : pas d’approbation qualité ni de réponse lorsque le corpus ne permet pas de conclure. Propriétaire : responsable métier du processus documentaire. Exploitant : équipe IT désignée. Autorité d’arrêt : propriétaire métier et responsable sécurité selon le motif. Ces informations sont validées ensemble.

La même période identifie les obligations à examiner : protection des données, contrats, droits sur les contenus et qualification de l’usage au regard des textes applicables. Le calendrier AI Act est vérifié sur les publications actuelles de la Commission, sans reprendre une date générale comme si elle s’appliquait à tous les systèmes. La fonction compétente conserve la décision juridique. Le programme assure que cette décision sera connue avant la mise en service et que son effet sur le périmètre est documenté.

Le premier passage de décision interdit trois raccourcis : propriétaire seulement nommé dans le projet, corpus dont les droits sont inconnus et exploitation reposant sur une personne non engagée dans le support. Si un de ces points manque, Sophie peut poursuivre une exploration isolée, mais ne présente pas le service comme candidat à l’ouverture. Le délai ne doit pas transformer une incertitude de responsabilité en risque d’exploitation implicite.

Jours 16 à 35 : fabriquer la référence de qualité

Les experts métier construisent un lot de questions représentatives et un lot de cas difficiles. Ils rédigent les réponses attendues, les sources admissibles et les situations où l’assistant doit s’abstenir. Le programme sépare les données qui servent au réglage de celles qui servent à la décision finale. Il note les langues, sites et types de documents absents du test. Une campagne ne peut pas démontrer la qualité sur une population qu’elle n’a jamais observée.

Le protocole distingue réponse correcte, réponse étayée et réponse utilisable. Une réponse peut être exacte mais citer le mauvais document ; elle reste difficile à contrôler. Une autre peut citer un texte exact tout en omettant une exception essentielle. Les erreurs critiques sont définies avant l’évaluation : accès non autorisé, instruction dangereuse ou confusion entre version approuvée et brouillon. Pour le scénario, aucune de ces erreurs n’est acceptée dans le lot de mise en service ; cette règle illustrative doit être adaptée à la criticité réelle.

Un registre d’écarts est rempli : question, sortie observée, source attendue, cause probable, responsable de correction et retest. Sophie refuse une liste d’incidents sans décision. Si plusieurs erreurs proviennent du corpus, l’équipe corrige sa qualité avant de changer le modèle. Si elles proviennent d’une récupération documentaire incorrecte, elle corrige cette étape. Ajuster la formulation des consignes ne doit pas devenir la réponse universelle à un problème de droits, de données ou d’architecture.

Jours 36 à 55 : installer les contrôles d’exploitation

L’IT démontre la propagation des habilitations, la suppression d’un document de l’index et la révocation d’un utilisateur. Les journaux permettent de retrouver la version du service, le corpus interrogé et les événements utiles à une analyse, en limitant la conservation des données sensibles. Le service dispose d’une surveillance de disponibilité, de coût et de qualité, ainsi que d’un mode dégradé connu des utilisateurs. Une interface affichée ne constitue pas un service disponible si ses sources ne sont plus accessibles.

Un runbook, c’est-à-dire une procédure d’exploitation, décrit quatre situations concrètes : fuite de droit, réponse non étayée, indisponibilité et dérive de coût. Pour chacune, il précise qui reçoit l’alerte, comment suspendre le flux, quel message adresser aux utilisateurs et quelles preuves conserver. Un opérateur différent du concepteur exécute la procédure en environnement de test. Si la seule personne capable d’arrêter le service est l’auteur du prototype, le transfert n’est pas terminé.

Le modèle de coûts inclut inférence, stockage, indexation, surveillance, support, évaluations et revue humaine. Le coût par demande utile conserve les tentatives rejetées dans le numérateur. Sophie documente les hypothèses de volume et de longueur des documents. Le budget comporte une alerte et une autorité de limitation ; il ne repose pas uniquement sur une facture reçue après le dépassement. Le contrôle des coûts est une capacité d’exploitation, pas une revue financière tardive.

Jours 56 à 75 : une ouverture limitée et réversible

Le pilote utilise une population autorisée, un corpus figé et un canal de retour simple. Les utilisateurs savent ce que le service peut faire, comment vérifier une source et quand revenir à la recherche habituelle. La formation porte sur des situations de travail : question ambiguë, absence de réponse, document incompatible avec le site. Un taux de connexion ne démontre pas l’appropriation ; l’équipe observe si les utilisateurs comprennent effectivement la limite de la sortie.

Sophie mesure le temps du parcours complet, vérification incluse, et le compare à des tâches comparables réalisées sans le service. Les commentaires sont reliés aux traces autorisées, afin de distinguer problème d’interface, mauvaise réponse et besoin hors périmètre. Les incidents ne sont pas effacés du bilan sous prétexte que l’utilisateur les a repérés. La détection humaine constitue une barrière utile, mais le coût et la fiabilité de cette barrière doivent être évalués.

Le pilote reste réversible. Les procédures existantes demeurent accessibles et aucune dépendance obligatoire n’est créée avant la décision. Une suspension ne doit pas empêcher le métier de travailler. L’équipe teste effectivement le retrait et la restauration de la dernière version acceptable. Elle observe aussi les demandes d’extension : ajouter un nouveau corpus ou donner un droit d’action ouvre une nouvelle analyse de risque, même si l’interface reste identique.

Jours 76 à 100 : décider et transférer

La dernière séquence ne cherche pas à remplir le bilan de succès. Elle rassemble qualité mesurée, incidents, couverture du test, coût complet, capacité de support et risques résiduels. Le comité dispose de quatre décisions : poursuivre dans le périmètre, étendre sous conditions, rester en expérimentation ou arrêter. Une extension exige ses propres responsables et contrôles. Une décision d’arrêt peut être une réussite du modèle de gouvernance si elle évite d’installer une dépendance non maîtrisée.

Le dossier de transfert contient la fiche de service, le journal de décisions, le protocole et les résultats d’évaluation, les procédures d’arrêt et de restauration, les engagements de support, le modèle de coûts et le calendrier de réévaluation. L’équipe d’exploitation accepte ce dossier et démontre les gestes nécessaires. Le programme ne disparaît pas avant que les propriétaires aient accepté les risques qu’ils devront assumer. Après le jour cent, les extensions relèvent d’un plan distinct, fondé sur cette capacité réelle.

Dans la vraie vie : une décision de limitation

Dans l’exemple, l’assistant fonctionne correctement sur les procédures du site pilote, mais échoue à distinguer plusieurs versions locales dans un corpus international. Sophie propose de conserver le service local et de différer l’extension. Elle ne transforme pas la restriction en détail technique invisible. Le propriétaire métier approuve la limite, les utilisateurs la voient et le backlog contient les preuves nécessaires pour rouvrir la décision. Aucun nombre d’usages industrialisés n’est annoncé sans définition et sans acceptation.

Adapter les cent jours au contexte

Dans une organisation réglementée, la validation du processus et des changements peut limiter ce qui est atteignable en cent jours. Dans un service juridique, les droits documentaires et l’autorité de validation structurent le pilote. Pour un agent IT capable d’exécuter des actions, ajouter une liste d’outils autorisés, des identités à privilèges limités, des plafonds d’exécution et des approbations humaines. Le calendrier reste un outil de préparation ; il ne doit pas forcer une ouverture avant que ces conditions soient démontrées.

Sources, méthode et limites

Sources primaires consultées le 4 octobre 2026. Le calendrier proposé est une méthode pédagogique et non une exigence normative. Il ne garantit ni conformité, ni qualité, ni gain financier dans une organisation donnée.