Back-office web augmenté par l’IA : du brouillon à l’action autorisée

Notre banc Edikka contient une lampe fictive, sa description, un prix de 89 € et un statut de brouillon. Un rédacteur prépare une reformulation ; un responsable peut l’approuver et l’appliquer. Seule la description est déléguée. Le prix et le statut restent hors du contrat. Le texte proposé est préparé à l’avance : aucun modèle n’est appelé.

Ce cas est une preuve de conception exécutée, pas le récit d’un déploiement client ni une mesure de productivité interne. L’intérêt est de pouvoir refaire l’essai. Pour la justesse des réponses et les évaluations de modèle, voir le protocole IA fiable. Le cas des métadonnées traite séparément le contenu des titles et descriptions.

L’IA n’obtient pas tous les droits de la personne connectée. Le périmètre effectif est l’intersection de ses droits courants, de la délégation utile à la tâche et des règles métier. Vérifier aussi le tenant, la fiche et le champ : « peut modifier une description » ne signifie pas « peut modifier toutes les descriptions ». Ces contrôles doivent précéder la lecture des données et l’écriture.

Dans le kit, chaque application ouvre une transaction SQLite, relit les droits de l’exécutant et de l’approbateur, vérifie l’empreinte de la révision approuvée, son expiration et la version de la fiche. Le contrôle et l’écriture appartiennent à la même transaction. Une empreinte lie le contenu ; elle n’est ni une signature ni un droit d’accès.

Extrait de l’écriture conditionnelle du serveur fourni, à lire avec les autorisations qui la précèdent. Une seule version attendue peut être remplacée. SQLite sérialise les écrivains dans ce laboratoire ; une architecture distribuée ou un envoi externe exige sa propre stratégie transactionnelle.

L’écran doit rendre vérifiables la source, les différences, les champs concernés, les informations manquantes et l’effet exact de l’action. Le banc sépare « Accepter cette version » et « Appliquer la description ». Le diff mot à mot isole la ponctuation, barre les suppressions et souligne les ajouts, en précisant la version enregistrée comparée. Il suit les corrections en cours. Une correction affichée mais non enregistrée désactive l’approbation, pour éviter de valider un texte différent de celui que l’on regarde.

Le biais d’automatisation invite à examiner la dépendance à la suggestion et les erreurs laissées après revue. Un taux d’acceptation élevé peut refléter de bonnes propositions ou une confiance excessive ; une revue courte peut être légitime sur une tâche simple. Aucun de ces signaux ne suffit seul à diagnostiquer le problème.

Éviter la friction décorative : ouvrir un diff ou attendre un compte à rebours ne démontre pas l’attention. Pour une revue sensible, demander la vérification d’un fait concret peut être pertinent ; il faut en mesurer l’effet sur les erreurs et la charge. Les tests humains proposés ci-dessous n’ont pas encore été exécutés sur ce banc.

Exécution du 11 octobre 2026 : 18 scénarios sur 18 passent, sur HTTP local et base SQLite temporaire. Deux scénarios déclenchent réellement deux requêtes concurrentes. Le dénominateur est un nombre de scénarios techniques, pas un nombre de personnes, de réponses IA ou de situations de production.

Les autres essais vérifient l’expiration, une empreinte falsifiée, les champs interdits, les rôles, le retour arrière nominal, les transitions sautées, une revue obsolète, la réutilisation d’une clé et des requêtes sans identité ou d’une autre origine. Les résultats et les empreintes du code sont dans le rapport complet. La recette navigateur FR/EN vérifie aussi qu’une sortie contenant du HTML reste du texte ; elle ne mesure pas la résistance d’un modèle à une injection.

Une génération rapide peut déplacer le travail vers la vérification. Comparer des tâches similaires en manuel, avec un gabarit lorsque pertinent, puis avec assistance. Contrebalancer l’ordre, conserver les abandons et faire auditer le résultat final indépendamment de son mode de production. Les petits effectifs restent exploratoires ; plusieurs tâches d’une même personne ne sont pas autant de participants indépendants.

Une « validation forcée » doit être définie : dans un outil qui permet de passer outre une alerte non bloquante, tracer le motif et auditer ces décisions. Un refus d’autorisation ne doit pas devenir contournable sous ce nom. Le banc ne propose aucun tel contournement. Zéro participant humain ici ; aucun gain de temps revendiqué. Le protocole vierge permet de préparer cette étude.

Dans ce banc, aucune donnée n’est envoyée à un prestataire : les textes et les identités sont fictifs. Dans une intégration réelle, inventorier les champs nécessaires avant l’appel, les droits de lecture, le destinataire, les usages contractuels, les transferts éventuels, la conservation et la suppression. Le contexte envoyé au modèle doit rester dans le périmètre autorisé.

Le journal du laboratoire est une table ordinaire, pas un registre inviolable. Arrêter le serveur supprime sa base temporaire. Les rapports publiés contiennent uniquement les données d’essai fictives. Aucun de ces choix ne constitue une certification RGPD ; le cadre réel dépend des données et des traitements retenus.

Le kit v1.0.0 réunit une matrice de permissions, un schéma JSON du journal et une checklist reliée aux essais. Il fournit aussi le serveur, son interface FR/EN, les 18 tests, les résultats bruts, un protocole de mesure humaine vierge et les empreintes. Le kit requiert Python ≥ 3.9. Les 18 scénarios ont été exécutés sous Python 3.9.6 ; aucune clé API ni dépendance à installer.

Après extraction, exécuter ces commandes dans le dossier du kit, puis ouvrir http://127.0.0.1:8876/?lang=fr. Le serveur est un laboratoire local : ses identités simulées sont volontairement accessibles. Ne pas l’exposer sur Internet ni le copier comme système d’authentification de production.

Code sous MIT ; documentation, schémas et données sous CC BY 4.0. Citer Edikka, titre du kit, version 1.0.0, URL et date de consultation. Les contrôles portent sur cette version précise : adapter la matrice et rejouer les tests avant toute transposition. Le guide IA fiable complète ce kit pour l’évaluation du système.

OWASP étaye les frontières d’autorisation et le traitement des sorties ; Microsoft et PAIR apportent des recommandations d’interface ; Parasuraman et Manzey traitent le biais d’automatisation ; la CNIL encadre les questions d’usage et de données. Leur portée ne remplace pas la recette de notre application. Les numéros LLM cités sont ceux de l’édition 2025.

Un back-office assisté devient crédible lorsque l’équipe peut comprendre la proposition, corriger ses erreurs et vérifier l’action réellement enregistrée. Choisir une première tâche, borner sa délégation, montrer le diff puis éprouver les conflits suffit à produire une première preuve utile. Élargir ensuite le périmètre seulement si la qualité et le travail humain le justifient. Cadrer ce premier parcours avec Edikka.