Deux modèles, et une facture qui n’explique pas tout

Le coût décide, puis il faut vivre avec ce que le coût a décidé.

Le modèle nominatif attribue un compte à un agent identifié : une adresse professionnelle, un mot de passe personnel, un historique de conversations qui n’appartient qu’à lui, et une licence facturée pour lui. Le modèle partagé crée des comptes génériques — un par direction, par service ou par métier — dont les identifiants sont remis à des référents qui les diffusent à leurs collègues. Plusieurs agents se connectent alors sous la même identité, parfois en même temps.

Les ordres de grandeur expliquent l’attrait du second. Dans un Département dont nous relayons le retour d’expérience, une vingtaine de licences d’un plan professionnel, un compte générique par direction et une trentaine de référents suffisent à ouvrir l’outil à environ deux cents utilisateurs, pour une dépense annuelle de quelques milliers d’euros réglée par une régie d’avances. Le même effectif équipé en nominatif change de catégorie de dépense : on quitte la régie, on entre dans une procédure d’achat, et le sujet remonte à la direction financière. Nous détaillons ces canaux dans un article dédié à l’achat d’un assistant sans marché de centrale d’achat.

Le raisonnement est juste, et c’est bien pour cela qu’il est dangereux : il est si convaincant qu’on oublie de le présenter au DPO comme ce qu’il est, c’est-à-dire le choix d’un modèle de traçabilité.

Ce que regarde un DPO, et qui n’a rien à voir avec le coût

Un compte partagé ne cache pas des données : il casse le lien entre une personne et un acte.

Le règlement général sur la protection des données demande à un responsable de traitement d’assurer l’intégrité et la confidentialité des données qu’il traite, et de mettre en œuvre des mesures techniques et organisationnelles adaptées au risque. En pratique, cela se traduit par un contrôle des accès dont on peut rendre compte : savoir qui a accédé à quoi, et à quel moment. Les guides de sécurité publiés par la CNIL vont dans le même sens et recommandent des comptes individuels, en écartant le partage d’identifiants entre plusieurs personnes ; il est prudent de vérifier leur rédaction en vigueur à la date à laquelle vous instruisez le dossier, ces documents étant régulièrement actualisés.

Avec un compte générique, l’outil conserve bien tout ce qui lui a été soumis, mais il l’attribue à une direction, pas à un agent. Les journaux d’administration comptent des conversations et des consommations par compte, sans jamais pouvoir dire lequel des vingt agents d’un service a collé le tableau des demandes d’aide sociale. Ce n’est pas un détail de documentation : c’est ce qui permet, ou ce qui empêche, de traiter un incident, de répondre à une demande d’accès et de tenir une sanction disciplinaire.

Sept points de friction du compte partagé

Aucun n’est rédhibitoire pris séparément. Ensemble, ils dessinent le périmètre de ce que l’on peut faire avec un compte générique.

Trois de ces points méritent d’être développés, parce qu’ils sont régulièrement découverts trop tard.

La contradiction avec la charte informatique déjà en vigueur

Presque toutes les collectivités disposent d’une charte d’usage des systèmes d’information qui interdit expressément à un agent de communiquer son mot de passe et d’utiliser le compte d’un collègue. Ouvrir un assistant d’IA en comptes partagés revient donc à instituer, par une note de service, une exception à un document que les mêmes agents signent par ailleurs. Cette contradiction se résout, mais explicitement : un compte de service, identifié comme tel, rattaché à un responsable nommé, avec une règle de diffusion écrite. Ce qui ne se défend pas, c’est le mot de passe qui circule par courriel sans que rien ne l’autorise.

Les connecteurs, le point le plus sous-estimé

Un assistant se connecte aujourd’hui à une messagerie, à un espace de fichiers, à un outil de gestion. Ces connecteurs changent la nature des données qui parviennent à l’outil : ce n’est plus ce qu’un agent colle dans une fenêtre, c’est tout ce à quoi le compte a accès. Sur un compte nominatif, ce périmètre coïncide avec les habilitations de l’agent. Sur un compte partagé, il devient le plus petit commun dénominateur de vingt personnes, et il faut se demander non pas si le connecteur est utile, mais qui, dans le service, n’aurait pas dû voir ce qu’il rapatrie. La règle qui tient : pas de connecteur sur un compte partagé.

La journalisation que l’on croit avoir

Les consoles d’administration des offres professionnelles fournissent des indicateurs d’usage et, selon les plans, des journaux d’audit. Ces éléments sont utiles au pilotage et à la mesure de l’adoption, et ils sont souvent présentés au DPO comme une garantie de traçabilité. Ils ne le sont pas dans un modèle partagé : ils tracent un compte. Vérifiez, avant de vous engager devant votre DPO, ce que la console expose réellement pour le plan que vous achèterez, car le contenu de ces journaux varie d’un plan à l’autre et évolue.

Ce que le nominatif règle, et le traitement qu’il crée

Le compte individuel ne supprime pas le sujet DPO. Il le déplace vers un terrain plus familier, celui du suivi des agents.

En nominatif, les sept frictions tombent presque toutes : l’acte est imputable, l’historique est privé, le mot de passe est personnel, l’authentification à double facteur redevient possible, le départ d’un agent se traite par la suppression d’un compte, et les connecteurs retrouvent un périmètre cohérent avec les habilitations. C’est le modèle cible d’un déploiement généralisé, et c’est aussi celui que l’authentification unique et le provisionnement automatique des comptes rendent administrable au-delà de quelques dizaines de sièges.

Deux difficultés apparaissent en échange. La première est la sélection des bénéficiaires. Quand le nombre de licences est inférieur à l’effectif, il faut désigner qui est équipé, et ceux qui ne le sont pas ne renoncent pas à l’outil : ils y retournent avec un compte personnel gratuit, hors de tout cadre. C’est le mécanisme que nous décrivons dans notre article sur le Shadow AI : l’écart entre ce qu’un agent peut faire chez lui et ce que son organisation lui propose est ce qui rend l’usage clandestin structurel. Un déploiement nominatif partiel produit exactement cet écart, avec en plus le sentiment d’une injustice interne.

La seconde est que la traçabilité individuelle est elle-même un traitement de données à caractère personnel. Savoir quel agent a envoyé combien de requêtes, à quelles heures et sur quels sujets, c’est une capacité de suivi de l’activité qu’il faut déclarer, limiter et encadrer. Trois précautions se justifient : informer les agents de ce qui est journalisé et pendant combien de temps ; écrire que les données d’usage ne servent ni à l’évaluation individuelle ni à une mesure de productivité, et désigner qui y accède ; examiner avec la direction des ressources humaines si l’instance de dialogue social doit être saisie, ce qui dépend de la portée du dispositif et de vos pratiques internes.

Autrement dit, le nominatif ne fait pas disparaître le travail du DPO : il échange un problème d’imputabilité contre un problème de proportionnalité, qu’une administration sait traiter.

À quelles conditions un compte partagé se défend

Un modèle d’expérimentation, borné dans le temps et dans son périmètre de données.

Notre position est que le compte partagé est défendable pendant la phase où l’on ignore encore quels cas d’usage méritent d’être industrialisés, et qu’il cesse de l’être dès qu’un usage devient régulier et utile. Cela suppose de l’assumer comme un dispositif transitoire, écrit comme tel, et non comme une économie durable.

Le premier bloc de conditions porte sur les données. Aucune donnée permettant d’identifier un usager ou un agent, aucune situation individuelle, aucune donnée relative à la santé, à l’action sociale, à la sécurité ou à une procédure en cours ; une consigne d’anonymisation avant toute soumission, outillée plutôt que laissée à la vigilance ; et l’interdiction explicite des connecteurs. Le Département dont nous relayons l’expérience a complété sa charte par une extension de navigateur qui affiche un rappel avant tout envoi vers un outil d’IA, et par un utilitaire d’anonymisation local qui remplace noms, montants, dates et identifiants d’entreprises. C’est la mesure compensatoire la plus efficace que nous ayons vue, parce qu’elle agit au moment du geste.

Le deuxième bloc porte sur les identifiants. Un compte de service déclaré comme tel, rattaché à une adresse fonctionnelle et non à la boîte d’un agent ; un responsable nommé par compte, qui sait qui détient le mot de passe et le consigne ; une remise des identifiants aux seuls référents, par un canal maîtrisé ; un renouvellement à date fixe et à chaque départ d’un détenteur ; et une revue périodique des comptes ouverts, parce qu’une licence dormante est à la fois une dépense inutile et un accès oublié.

Le troisième bloc porte sur la traçabilité de substitution. Puisque l’outil ne peut pas la fournir, elle se construit autour : un registre des détenteurs par compte et par période, tenu à jour ; une purge régulière de l’historique partagé, dont la fréquence est écrite ; une date de fin pour l’expérimentation, avec le critère qui déclenche le passage au nominatif. Ce critère est le point le plus important du dispositif, et c’est presque toujours celui qui manque.

Ce qu’il faut écrire, et ce qu’il faut demander à l’éditeur

Le modèle de compte se lit dans trois documents, et se vérifie dans un quatrième.

Au registre des traitements, la fiche consacrée à l’assistant d’IA générative mentionne les catégories de personnes concernées — les agents utilisateurs, et les personnes susceptibles d’être citées dans ce qui est soumis à l’outil —, les catégories de données admises, le sous-traitant et ses propres sous-traitants, le lieu des traitements, le fondement du transfert hors Union européenne s’il y en a un, la durée de conservation des conversations et des journaux, et le modèle de compte retenu avec sa date de fin. Ce dernier point est la seule information qui permettra, dans un an, de savoir si le dispositif est resté celui qui a été décrit.

Une analyse d’impact relative à la protection des données n’est pas automatique : elle dépend des traitements envisagés, et c’est au DPO d’apprécier si les critères sont réunis. Notre observation est simple : cette appréciation est beaucoup plus facile quand les cas d’usage sont décrits un par un, avec les données qu’ils appellent, qu’à partir de la question générale « peut-on utiliser cet outil ». C’est précisément ce que produit un travail de qualification des cas d’usage.

Dans la charte, le modèle de compte appelle trois clauses : les catégories de données interdites, le régime des comptes de service et de leurs identifiants, et le réexamen périodique des fonctions autorisées, connecteurs compris. Notre modèle de charte IA de collectivité propose pour chacune un texte type et un commentaire qui donne les variantes observées.

Reste ce qu’il faut obtenir de l’éditeur, et qui ne s’obtient bien qu’écrit : l’accord de traitement des données et la liste de ses sous-traitants ultérieurs, la localisation des traitements et le mécanisme de transfert invoqué, la durée de conservation des contenus soumis et des journaux, l’engagement de non-utilisation des contenus pour l’entraînement des modèles dans les offres professionnelles, le détail de ce que la console d’administration journalise selon le plan, les modalités d’export et de suppression des données en fin de contrat, et la position contractuelle sur le partage d’identifiants. Ces éléments évoluent : ils se lisent dans la documentation contractuelle à la date de lecture, et non dans un article. Notre modèle de CCTP d’assistance à maîtrise d’ouvrage en fait une exigence de production de pièces, pour que la comparaison entre solutions se fasse sur des réponses écrites et non sur des plaquettes.

Comment nous traitons ce point en assistance à maîtrise d’ouvrage

La question du modèle de compte arrive au cadrage, pas à la fin.

Nous arrivons déjà outillés pour que l’expérimentation démarre dans les premières semaines, et le modèle de compte fait partie de ce qui est posé dès le cadrage, avec le canal d’achat, les fonctions ouvertes et les cas d’usage à mesurer. Concrètement, nous écrivons avec vous la liste des données admises, le régime des comptes de service, le critère de bascule vers le nominatif et les questions à poser à l’éditeur ; nous préparons le dossier que votre DPO attend, plutôt que de lui demander un avis sur un outil.

Et nous rapportons le coût au bon numérateur. L’économie apparente d’un modèle partagé se compare non pas au prix des licences nominatives, mais au coût complet du programme : le temps de la cellule qui administre, la formation des référents, la maintenance des petits outils que les agents finissent par construire, et les licences dormantes qu’on paie sans les utiliser. Piloter cette frugalité — les coûts et le carbone — sur l’ensemble du programme, toutes solutions confondues, est ce qui distingue une assistance à maîtrise d’ouvrage d’un revendeur de licences.

La frugalité est une grille d’arbitrage, jamais un motif d’exclusion : elle sert à prioriser les cas d’usage, à dimensionner au besoin réel et à éliminer ce qui ne sert pas, pas à écarter une solution du comparatif.

Questions fréquentes

Lien direct : calendar.app.google/8FprCJKk4xFnm4f57