Un assistant IA peut-il mettre à jour le système de gestion ? Comment délimiter les actions

Un assistant qui se trompe dans une réponse se corrige en relisant. Un assistant qui se trompe dans une écriture laisse une donnée erronée dans le système de gestion, et de là partent une facture, une livraison ou un appel à un client. C'est la même technologie, mais le risque change de nature : on passe d'une information discutable à une opération accomplie.

La question « l'intelligence artificielle peut-elle mettre à jour le système de gestion ? » n'a donc qu'une seule réponse utile : oui, sur des opérations définies à l'avance, avec ses propres permissions, avec un contrôle avant l'écriture et avec un registre de ce qu'elle a fait. Tout le travail consiste à décider de quelles opérations.

Lire, proposer, écrire : trois niveaux, trois risques

La distinction la plus utile n'est pas technique mais organisationnelle, et elle concerne qui assume le résultat.

Presque tous les projets utiles vivent dans les deux premiers niveaux. Le troisième s'accorde aux opérations répétitives et réversibles ; le quatrième, en pratique, ne s'accorde pas.

L'assistant n'est pas un administrateur : il hérite des permissions d'un rôle

L'erreur de configuration la plus fréquente est de connecter l'assistant avec un accès qui peut tout faire, parce que c'est plus rapide à configurer. À partir de ce moment, chaque limite ne dépend plus que des instructions données au modèle, c'est-à-dire de la partie la plus facile à contourner.

• L'assistant a son propre compte, distinct de ceux des personnes, avec les permissions minimales pour les tâches assignées.
• S'il répond à des utilisateurs différents, il doit voir ce que verrait cet utilisateur : un commercial ne doit pas pouvoir obtenir via l'assistant des données que le système de gestion lui refuse.
• Les outils connectés forment une liste fermée. « Il peut interroger la base de données » n'est pas une liste : c'est un accès général sous un autre nom.
• Les tests se font sur un environnement séparé, pas sur les données de production, et doivent être répétés chaque fois que les permissions changent.

Les écritures se délimitent par champ, pas par bonnes intentions

Délimiter signifie écrire la liste des opérations admises, chacune avec ses champs et ses conditions. Ce qui n'est pas dans la liste n'est pas possible, pas seulement déconseillé : c'est toute la différence.

• Quels champs l'opération peut toucher, et lesquels restent en lecture seule même quand l'assistant en parle.
• Quelles valeurs sont admises : une date future, un statut parmi ceux prévus, un client qui existe. La validation se trouve dans le système, pas dans les instructions écrites au modèle.
• Sur quels enregistrements : les siens, ceux qui sont ouverts, ceux de la période en cours. Le cas « mettre à jour tous les clients » ne doit pas pouvoir exister.
• Combien de fois : une limite au nombre d'opérations par session empêche qu'un malentendu ne devienne un travail d'heures à annuler à la main.

Un flux d'exemple : déplacer un rendez-vous

Opération répétitive, à faible risque, avec un client de l'autre côté. Séquence illustrative.

1. Une demande arrive : « Le technicien de jeudi peut-il venir vendredi matin ? » L'assistant identifie de quel rendez-vous il s'agit et, si les données ne suffisent pas, demande au lieu de deviner.
2. Il vérifie les conditions : le rendez-vous existe, il n'est pas déjà clos, celui qui écrit a le droit de le déplacer, la nouvelle date est disponible pour ce technicien.
3. Il prépare la proposition avec les valeurs remplies : ancienne date, nouvelle date, technicien, client.
4. Il montre la proposition à celui qui doit l'autoriser et attend un consentement explicite. Le consentement vaut pour cette proposition, pas pour les suivantes.
5. Il exécute la seule opération autorisée, avec un identifiant qui empêche de l'appliquer deux fois si la demande est répétée.
6. Il enregistre le résultat et communique ce qui a changé. Si l'opération échoue, il le dit ouvertement : un assistant qui rapporte un succès qui n'a jamais eu lieu est pire qu'un assistant qui se trompe.

L'étape qu'on coupe en premier, et qui pourtant soutient tout, est la quatrième. Sans une confirmation explicite, le système n'est plus délimité : il est seulement bien instruit, et les instructions ne sont pas une limite.

Doublons, répétitions et comment revenir en arrière

Les demandes se répètent : quelqu'un réécrit, le réseau tombe, l'assistant réessaie. Si chaque tentative produit une opération, on se retrouve avec trois rendez-vous déplacés et deux avis envoyés au client.

• Chaque opération porte un identifiant dérivé de la demande : si elle arrive deux fois, la seconde ne produit rien.
• Avant de créer quelque chose, on cherche si cela existe déjà : un client, une commande, un rendez-vous similaire le même jour.
• Pour chaque opération, il faut écrire comment on l'annule et qui peut le faire. Certaines sont réversibles, d'autres non : un message envoyé à un client ne se retire pas, et cela suffit à le déplacer parmi celles qui exigent une confirmation humaine.
• Les opérations effectuées en séquence doivent être pensées comme un bloc : si la troisième échoue, il faut décider à l'avance si les deux premières restent ou doivent être annulées.

Le registre : quoi, quand, à la demande de qui

Sans registre, on ne peut pas répondre à la question qui arrive tôt ou tard : pourquoi ce rendez-vous a-t-il été déplacé ? Le registre sert à reconstituer, pas à blâmer.

• La demande d'origine, l'opération exécutée et les valeurs écrites.
• Qui a autorisé, quand et par quel canal.
• Le résultat, y compris les tentatives échouées et les opérations rejetées par les contrôles.
• Combien de temps il se conserve et qui peut le consulter : le registre contient des données de l'entreprise et parfois personnelles, et se protège comme le reste.

Les refus enregistrés sont la partie la plus utile pendant les premiers mois : ils disent ce que l'assistant a essayé de faire et n'a pas pu. C'est à partir de là qu'on comprend si les limites sont trop étroites ou trop larges, sans avoir à le découvrir par une erreur.

Ce que ce guide ne couvre pas

Ici, on traite le contrôle des actions : quelles opérations sont permises, qui confirme, comment on les enregistre. Les vérifications techniques pour relier deux logiciels entre eux, c'est-à-dire ce que chacun expose et ce qui se passe quand l'un change, sont un sujet à part. C'est aussi le cas de la défense contre les instructions trompeuses cachées dans les documents ou les messages que l'assistant lit : c'est un risque différent, avec ses propres contre-mesures.