Ce qu’une expérimentation réussie fabrique

Le mécanisme est régulier, et il est le signe que l’expérimentation a marché.

Un service éprouve un cas d’usage sur sa propre matière et obtient un résultat. Il veut le garder. Deux chemins s’offrent à lui : écrire une procédure, qui demande des semaines et une relecture par trois personnes, ou configurer l’outil, qui demande une après-midi. Il configure l’outil. Ce n’est pas une paresse, c’est le rapport de temps entre les deux gestes — et le choix est fait avant que quiconque l’ait arbitré.

Ce qui se dépose alors dans l’objet est précisément ce qui aurait dû aller dans la procédure : le règlement que le service applique, la liste des pièces qu’il contrôle, l’ordre dans lequel il travaille, les cas limites qu’il a rencontrés. L’objet est donc la seule version écrite du savoir-faire du service, et elle n’est écrite nulle part ailleurs.

Dix-huit mois plus tard, trois choses se sont produites. L’objet a figé une interprétation du règlement que personne n’a délibérée. Son auteur a changé de direction, et la personne qui s’en sert tous les jours ne sait ni ce qu’il contient ni comment le corriger. Et personne ne sait combien il y en a dans la collectivité, parce qu’aucun objet n’a jamais été déclaré : il n’y avait rien à quoi le déclarer.

Dans un Département dont nous relayons l’expérience, les directions ont produit en quelques mois des applications internes qui font gagner du temps, dont une qui épargne près d’une heure par jour à deux agents. Le sujet qui est remonté à la cellule pilotant le programme n’était ni le choix du modèle, ni la charte, ni la conformité : c’était de savoir où ces objets vivent et qui les maintient le jour où leur auteur change de poste. La formule employée pour désigner cette question était « la pièce manquante ».

Le critère qui fait entrer un objet dans le parc

Une seule question suffit à trier, et elle ne porte pas sur la technique.

À la fin de la tâche, quelque chose a-t-il changé ailleurs que dans la fenêtre de l’outil ? C’est le critère que nous employons pour distinguer un usage d’un objet, et il est volontairement grossier. Un agent qui pose une question, lit une réponse, en reprend trois phrases dans son courrier et ferme la fenêtre n’a rien laissé derrière lui : la seule question que pose cet usage est celle de la relecture. Un agent qui a configuré un espace de travail que son collègue ouvrira demain, ou déposé un fichier qui s’exécute, a produit un objet.

Deux critères rendent ce test opérationnel, et il suffit que l’un des deux soit vrai. La réutilisation par un tiers : quelqu’un d’autre que l’auteur s’en sert, ou s’en servira. L’exécution sans son auteur : l’objet produit quelque chose alors que la personne qui l’a construit n’est pas devant. Le premier critère fait entrer les assistants configurés et les gabarits partagés ; le second fait entrer les applications et les tâches programmées.

Trois questions permettent de le vérifier sans entretien technique, et un agent y répond en une minute. Est-ce que je serais gêné si cet outil disparaissait demain matin ? Est-ce que quelqu’un d’autre l’ouvre ? Est-ce qu’il produit quelque chose quand je ne suis pas là ? Deux « oui » suffisent à déclarer.

Le critère a une vertu sur laquelle il faut insister : il ne demande à personne de juger si un objet est « une vraie application ». Cette qualification est exactement ce sur quoi un service et une direction informatique ne s’accorderont jamais, et attendre l’accord revient à ne rien recenser. Le critère déplace la question vers un constat de fait, et un constat de fait se tranche.

Quatre familles d’objets, quatre engagements

Elles ne demandent ni le même lieu, ni la même surveillance, et les confondre conduit à sur-encadrer les plus légères et à laisser courir les plus lourdes.

L’ordre n’est pas décoratif : il correspond au coût de la reprise. Un assistant configuré se reprend en déplaçant son référentiel et en désignant quelqu’un pour le tenir. Une application de service se reprend en trouvant une machine, ce qui est le sujet de ce dossier. Une automatisation déclenchée ne se reprend pas vraiment : elle se réécrit, parce que ce qui compte en elle est son périmètre d’action, et qu’un périmètre se décide, il ne se transfère pas.

Les deux premières familles sont les seules qu’une collectivité sans direction informatique peut tenir aujourd’hui. Les deux dernières demandent un lieu d’exécution, et c’est là que la plupart des programmes butent.

Pourquoi ce n’est pas le Shadow IT qu’on connaît

Les directions informatiques traitent depuis vingt ans les bases de données et les tableurs que les services fabriquent dans leur coin. Ce parc-ci se comporte autrement, pour trois raisons.

L’objet porte une interprétation du droit ou d’un règlement, et pas seulement une fonction. Un tableur qui additionne une colonne a tort ou raison, et l’erreur se voit. Un assistant qui instruit un dossier choisit une assiette que le règlement ne définit pas, retient une lecture plutôt qu’une autre sur une pièce ambiguë, et applique ce choix à tous les dossiers suivants. L’erreur, ici, n’est pas un faux calcul : c’est une doctrine installée par défaut. Aucun contrôle technique ne la détecte, parce qu’il n’y a rien de techniquement faux.

Son auteur n’est pas développeur et ne peut pas rendre compte de ce qu’il a fabriqué. Il peut dire ce qu’il voulait obtenir ; il ne peut pas dire ce que l’objet fait dans les cas qu’il n’a pas essayés. C’est une différence de nature avec le tableur de service, dont l’auteur, aussi peu technique soit-il, voyait ses formules. La conséquence pratique est qu’un recensement déclaratif ne suffit pas : il faut aussi, pour les objets critiques, quelqu’un qui les éprouve sur des cas difficiles choisis à l’avance.

Il s’écrit plus vite qu’il ne se recense. Une base de données de service demandait des semaines, ce qui laissait à l’organisation le temps de la voir venir. Un assistant configuré demande une après-midi. Un inventaire annuel est donc structurellement en retard, et c’est pourquoi la déclaration à la création est la seule méthode qui tienne — à condition qu’elle coûte deux minutes, et non un dossier.

Il existe une quatrième différence, et c’est une bonne nouvelle. Ces objets sont documentés par construction : leurs instructions sont du texte en français, lisible par un non-technicien, et leur référentiel est fait des documents que le service applique déjà. Un tableur de service devait être reconstitué par lecture de ses formules ; ici, la documentation existe, elle est juste éparpillée. Le recensement d’un parc d’objets d’IA générative est moins coûteux que celui du Shadow IT classique, à condition qu’il soit organisé pendant que les objets se créent.

Les trois décisions à prendre avant l’ouverture

Elles tiennent en une page de charte ou de cahier des charges. Prises après, elles coûtent un audit et une négociation service par service.

Ces trois décisions ne se valent pas quant à l’urgence, et il est utile de savoir laquelle attend.

Le registre se construit rétroactivement, à un prix connu : une enquête auprès des directions, qui trouvera ce que les gens déclarent. Et personne ne déclare spontanément un objet dont il craint de perdre l’usage. Un recensement fait après coup rapporte donc une fraction du parc, et la fraction manquante est précisément celle qui compte, puisqu’elle est faite des objets dont les services dépendent le plus.

Le seuil de reprise s’écrit à tout moment, mais appliqué rétroactivement il devient un exercice de requalification. Dire à un service, deux ans après, que l’outil dont il se sert tous les jours relève désormais de règles qu’il n’a pas vues venir est une conversation qui se passe mal, et qui se termine souvent par un objet qui continue d’exister en dehors du registre.

Le lieu est la seule des trois qu’on ne peut pas prendre rétroactivement sans un travail de reprise. Déplacer un objet qui marche, du poste de son auteur vers un endroit partagé, demande de réécrire ses accès, ses chemins de fichiers, parfois sa logique entière. Le service n’y gagne rien d’immédiat : son outil fonctionnait. Il résiste, et il a raison de résister, parce que le bénéfice de l’opération est pour la collectivité et le coût pour lui. C’est pourquoi le lieu doit exister avant que les objets de la troisième et de la quatrième famille n’apparaissent — et c’est pourquoi une collectivité qui n’en a pas devrait dire que ces deux familles ne sont pas ouvertes, plutôt que les laisser s’installer sur des postes.

Le registre : ce qu’il contient et qui le tient

Huit colonnes, une déclaration à la création, un relevé annuel. Rien de plus, sous peine de n’être pas rempli.

Le registre d’un parc d’objets d’IA générative n’est pas un inventaire d’actifs informatiques et ne se tient pas dans le même outil. Il décrit ce que la collectivité fait faire, à quoi, avec quoi, et sous la responsabilité de qui. Huit colonnes suffisent.

Le nom de l’objet et ce qu’il produit, en une phrase de métier et non de logiciel — « prépare la fiche d’instruction d’une demande de subvention », pas « assistant du service vie associative ». Sa famille, parmi les quatre ci-dessus. Son propriétaire, qui est une personne nommée et non un service : un service ne répond pas d’un objet, une personne si. Le référentiel qu’il applique, avec la date de la version employée. La machine ou l’espace où il tourne. Les données qu’il voit effectivement. Ce qu’il peut écrire ou envoyer, et vers où. Et la date de sa dernière révision, avec celle de la prochaine.

Deux colonnes résistent, et ce sont les deux qui servent. La première est celle des données vues effectivement : la réponse utile n’est pas une liste de catégories autorisées, c’est le contenu réel du dossier ou de l’espace auquel l’objet a accès, tel qu’il est aujourd’hui. L’écart entre les deux formulations est tout le sujet, et il se constate en ouvrant le dossier plutôt qu’en lisant une note. La seconde est celle de ce que l’objet peut écrire ou envoyer : c’est elle qui sépare un outil qui propose d’un outil qui agit, et c’est la seule colonne dont la réponse doit être relue par quelqu’un d’autre que l’auteur.

Une neuvième colonne mérite d’être ajoutée dès que le parc dépasse quelques objets : les points que l’objet a dû trancher faute de règle écrite, et la date à laquelle ils ont été remontés. Nous y revenons plus bas, parce que c’est la colonne qui transforme le registre en instrument de gouvernance au lieu d’un simple inventaire.

Qui le tient ? L’instance qui arbitre les cas d’usage, avec un agent nommé pour la tenue courante — et non la direction informatique seule, qui n’a pas à juger de l’interprétation d’un règlement de subvention. Si une telle instance n’existe pas, le registre n’aura pas de destinataire et ne sera pas rempli : créer l’instance est alors la première décision, et elle précède les trois autres.

Le lieu unique, ou la pièce manquante

Trois dispositions, de la plus légère à la plus exigeante. La troisième est celle qui manque presque partout.

Cette dernière phrase est celle qui compte, et elle conduit à un conseil inconfortable. Une collectivité sans direction informatique — et il y en a plus qu’on ne le suppose, y compris de taille respectable — ne peut pas tenir la disposition C aujourd’hui. La réponse honnête est alors de limiter le parc aux deux premières familles et de dire que les deux autres ne sont pas ouvertes, en attendant que la question ait un titulaire. Écrire ce refus vaut mieux que laisser les objets s’installer sur des postes, parce qu’un refus écrit se lève le jour où le lieu existe, tandis qu’un parc dispersé se reprend à la main, objet par objet.

Il existe une voie intermédiaire, et c’est celle qui nous paraît la plus prometteuse pour les communes et les petits établissements : la mutualisation. Un établissement public de coopération intercommunale, un syndicat mixte de systèmes d’information, un centre de gestion peuvent tenir ce lieu pour plusieurs collectivités, et rien dans la nature du besoin ne s’y oppose — ce sont des objets petits, peu consommateurs, et dont les règles d’hébergement sont les mêmes d’une collectivité à l’autre. C’est exactement le genre de besoin qui se spécifie avant d’être acheté, et c’est ce qu’une assistance à maîtrise d’ouvrage sert à écrire.

Le seuil de reprise, et ce que reprendre veut dire

Trois critères, écrits avant d’en avoir besoin. Et trois régimes de reprise, parce qu’un seul régime conduit toujours au même résultat : rien.

Le seuil répond à une question simple : à partir de quand un objet fabriqué par un service cesse d’être un outil personnel pour devenir quelque chose dont la collectivité répond ? Trois critères suffisent, et aucun des trois ne s’écrit utilement sous forme de chiffre, parce que le chiffre juste dépend de la taille et de l’organisation de chaque collectivité.

La dépendance d’un tiers. Le critère opérant n’est pas le nombre d’utilisateurs mais le fait que quelqu’un d’autre que l’auteur en ait besoin pour faire son travail. Un objet dont deux agents dépendent est plus engageant qu’un objet que douze personnes ouvrent de temps en temps.

La criticité. Que se passe-t-il si l’objet cesse de fonctionner pendant une semaine ? Si la réponse est qu’une échéance est manquée, qu’un acte part en retard ou qu’un usager n’obtient pas de réponse, l’objet relève des règles applicables aux applications, quelle que soit sa taille.

La sensibilité des données. Dès que l’objet voit des données nominatives, il entre dans le périmètre des règles de la collectivité, sans discussion et sans seuil. Ce critère-là n’est pas graduel.

À ces trois critères s’ajoute un déclencheur, qui n’en est pas un quatrième mais qui provoque plus de reprises que les trois autres réunis : le jour où l’auteur de l’objet annonce son départ ou sa mobilité. Inscrire ce déclencheur dans le processus de départ d’un agent coûte une ligne et épargne la découverte, six mois plus tard, d’un outil que plus personne ne sait faire tourner.

Ce que l’objet fige, et que personne n’a délibéré

Le risque de ces objets n’est pas qu’ils inventent. C’est qu’ils tranchent, sans qu’aucun contrôle ne le signale.

Nous avons éprouvé ce point dans le cadre de notre lettre d’information, sur une tâche d’instruction préparatoire de demandes de subvention d’associations, écrite pour l’occasion : un règlement d’attribution, une liste de pièces, un modèle de fiche d’instruction, trois dossiers déposés, et — ce qui rend la mesure possible — une liste de référence de trente éléments que l’instruction doit contenir et seize difficultés placées à la rédaction, donc connues avant la mesure.

Le dispositif ne comparait pas des outils. Il faisait varier une seule chose : ce que le service donne à l’objet qu’il construit. Rien, d’abord. Puis ses documents, c’est-à-dire le règlement, la liste des pièces et le modèle de fiche. Puis ses documents précédés de six lignes de méthode qui ne contenaient aucune information sur les dossiers.

Avec rien : dix-neuf éléments de référence sur trente, cinq difficultés fondées sur seize, et pas un seul renvoi à un fondement, puisqu’il n’y en avait aucun à citer. Avec les documents du service : vingt-neuf éléments sur trente, seize difficultés sur seize, quatre-vingt-dix-sept renvois à un article du règlement. Avec les documents et la méthode : trente sur trente, seize sur seize, cent cinquante-neuf renvois et dix-sept calculs écrits en clair. Aucune des trois sorties n’a inventé un montant, une date ou un nom, et aucune n’a proposé de montant à attribuer.

Deux résultats concernent directement la gouvernance d’un parc.

Le premier : la sortie sans référentiel n’invente rien, elle induit sa norme du lot. Faute de règle, elle juge un dossier par comparaison avec les autres — « le dossier est, sur le plan des comptes, le plus complet des trois » — puis applique au deuxième la norme tirée du premier. Rien n’est inventé, donc aucun contrôle qui cherche les fausses informations ne le verra passer. Et sur soixante dossiers, les premiers instruits deviennent la règle appliquée aux suivants, sans que personne l’ait décidé. C’est un mode de défaillance propre à ces objets, et il demande un contrôle propre : vérifier si un constat est justifié par comparaison avec un autre élément du lot plutôt que par le référentiel.

Le second : même avec son référentiel, l’objet doit trancher là où le référentiel se taît. Le règlement du test ne définissait pas l’assiette d’un plafond qu’il rendait pourtant opposable. La sortie outillée de la méthode a donné les deux calculs possibles plutôt que d’en choisir un, et a signalé la lacune. C’est le bon comportement, et il n’est pas spontané : il était écrit dans la méthode. Sans cette ligne, l’objet choisit, et son choix devient la doctrine de la collectivité sans qu’aucune instance l’ait délibéré.

D’où la neuvième colonne du registre, et la règle qui va avec : les interprétations que l’objet est obligé de faire, faute de règle écrite, remontent une fois à l’instance qui décide, et non dossier par dossier. Une lacune de règlement qui remonte une fois produit une décision ; la même lacune laissée à l’objet produit une pratique.

La relecture est la dépense récurrente

Le coût visible d’un objet fabriqué en interne est nul. Le coût réel est quotidien, et c’est lui qui décide si l’objet valait la peine.

Un objet construit par un service ne crée aucune dépense nouvelle quand le compte professionnel existe déjà. Son coût de fabrication est du temps d’agent : celui qu’il faut pour mettre par écrit un référentiel et une méthode que personne n’avait jamais écrits. C’est une dépense unique, et elle est bien employée, puisque ce qui est écrit sert au service même si l’objet est arrêté plus tard.

La dépense qui se répète est la relecture de ce que l’objet produit. Sur l’essai d’un traitement nocturne que nous avons mené pour la lettre d’information, l’ordre de grandeur que nous avons retenu est de dix à vingt minutes par jour pour la relecture du matin — chiffre tiré de notre propre essai, non du déploiement d’une collectivité, et donné comme un ordre de grandeur à vérifier sur la tâche réelle. C’est cette ligne, et non le prix de la licence, qui décide de la rentabilité d’un objet. Un objet qui fait gagner trente minutes et demande vingt minutes de relecture n’est pas un gain de trente minutes.

Deux conséquences pour le pilotage, et la seconde est la plus souvent oubliée.

La première est qu’il faut inscrire la relecture quelque part. Ni le service qui a fabriqué l’objet ni la direction informatique ne la portent spontanément : elle n’est le métier de personne, et c’est précisément pourquoi elle disparaît. Un objet de la quatrième famille sans relecteur nommé est un objet qui agira pendant des mois sans que personne lise ce qu’il fait.

La seconde touche à la frugalité, et c’est le même raisonnement que celui des droits dormants. Un objet qui tourne chaque nuit pour produire une sortie que personne n’ouvre est un actif dormant : il consomme, il engage, et il ne rend rien. L’indicateur utile d’un parc n’est donc pas le nombre d’objets, qui ne mesure que l’enthousiasme, mais le taux d’ouverture de ce qu’ils produisent. Un parc de quarante objets dont douze sont lus est un parc de douze objets et vingt-huit dettes. Nous développons ce raisonnement sur notre page consacrée à l’AMO IA, où il s’applique aussi aux licences.

Ce qui s’écrit dans la charte, ce qui s’écrit dans le CCTP

Quatre lignes dans l’une, une page dans l’autre. Les deux documents sont en accès libre sur ce site.

Dans la charte d’usage, quatre lignes suffisent, et elles sont rédigées en obligations de l’agent plutôt qu’en interdictions d’outil.

Un objet réutilisé par un tiers ou exécuté sans son auteur est déclaré au registre avant d’être partagé. Il a un propriétaire nommé, un référentiel daté et une date de révision. Il ne conclut jamais sur l’opportunité d’une décision ni sur un montant : ce qu’il rend est un projet, que quelqu’un valide et signe. Et pas d’outil agentique sur un compte partagé.

Cette dernière ligne demande un mot d’explication, parce qu’elle paraît sévère dans les collectivités qui ont déployé des comptes de service. Tant que l’outil répond, l’acte tracé est une question posée, et un compte partagé est un inconvénient de traçabilité. Dès que l’outil agit, l’acte tracé est l’écriture d’un fichier ou l’envoi d’un message, et les droits d’un compte collectif excèdent par construction ceux de chacun de ses membres. La règle ne demande pas de basculer tout un déploiement en nominatif : quelques comptes nominatifs dédiés aux objets qui agissent suffisent, et la disposition B les impose de toute façon.

Quatorze articles, avec le commentaire de chacun. En accès libre, sans formulaire.

Dans le cahier des clauses techniques d’une assistance, la même question tient en une page, et sa place est dans le périmètre de la mission plutôt que dans ses livrables. Le titulaire traite la question avant l’ouverture et non après : recensement des objets existants, lieu unique d’hébergement et d’exécution, critères de bascule écrits à l’avance. Et l’article des livrables demande un format source modifiable, pour une raison qui apparaît ici avec netteté : un objet dont les instructions et le référentiel ne sont remis qu’en format de lecture ne se reprend pas, et une collectivité qui ne peut pas reprendre ses objets doit racheter la prestation à chaque mobilité d’agent.

Dix-sept articles en quatre parties, quatre annexes, un commentaire par article.

Les quatre erreurs les plus coûteuses

Elles ne sont pas de méthode, elles sont de séquence : chacune consiste à faire une bonne chose dans le mauvais ordre.

Il existe une cinquième erreur, plus rare et plus coûteuse encore : acheter une solution métier pour remplacer un objet qu’on n’a pas évalué. Un objet fabriqué par un service est un cahier des charges écrit par l’usage, et c’est sa plus grande valeur — il dit combien d’agents en dépendent, ce que la tâche demande vraiment, et quels cas limites existent. L’acheter avant de l’avoir lu revient à payer pour découvrir ce qu’on avait déjà.

Nos ressources sur ce sujet

Le modèle de charte et le modèle de CCTP ci-dessus portent les clauses décrites dans cet article. La grille comparative et le guide d’achat servent l’étape suivante, quand un objet éprouvé conduit à une consultation.

Modèle de charte, modèle de CCTP, grille comparative des solutions et guide d’achat. Sans formulaire.

Questions fréquentes

Lien direct : calendar.app.google/8FprCJKk4xFnm4f57