« Invisible » sonne marketing. C’est une facture d’ingénierie.
Dans notre bilan du mois un nous avons écrit : « la gouvernance doit être invisible — pas absente. Tout le reste est contourné. » Cette phrase se lit comme un slogan. C’est en fait une facture d’ingénierie à six chiffres. Nous venons d’en payer un morceau.
La plupart des échecs de gouvernance que nous voyons sur le terrain — l’IA qui a envoyé à un client quelque chose qu’elle n’aurait pas dû, l’appel d’outil qui a franchi une frontière de tenant, la file d’approbation qui s’est remplie et a été approuvée en bloc sans lecture — n’arrivent pas parce que les contrôles manquaient. Ils arrivent parce que les contrôles étaient suffisamment pénibles pour que les opérateurs les contournent. Les contrôles étaient là. Ils ont juste perdu la guerre quotidienne de la friction.
La semaine dernière (2026-04-22 à 2026-04-29) nous avons livré six choses. Chacune lime un bord spécifique du workflow opérateur tout en conservant (souvent en renforçant) la piste d’audit sous-jacente. Ce post est ce qu’il y avait réellement sur ces PR et pourquoi chacun valait la peine.
1. Les 13 handlers de quick-action qui contournaient discrètement les approbations
Le Concierge — le copilote IA de JieGou qui vit à côté de chaque espace de travail opérateur — était initialement câblé avec 13 handlers de quick-action (Brouillon de réponse, Composer une relance, Suggérer un changement de statut, Tagger comme, Mettre en pause, etc.). Chacun était un chemin de code indépendant qui pouvait déclencher une action directement, parce qu’ils précédaient la file d’approbation unifiée.
Fonctionnellement, ils marchaient. Architecturalement, c’était un trou de gouvernance en forme de 13.
Le fix : chaque action initiée par le Concierge passe désormais par le même pipeline d’approbation yellow-gate que tout le reste de la plateforme. Pas une nouvelle file d’approbation — la même file. Les seuils par action (auto-execute, yellow-gate, red-gate) sont définis par compte ; les valeurs par défaut correspondent au profil de risque de chaque vertical.
Le format du log d’audit est resté identique (audit_event avec les mêmes champs), donc les revues de gouvernance n’ont pas à traiter spécialement « ça vient du Concierge ». Chaque point d’entrée — workflow, API, panneau latéral, bouton d’e-mail — produit la même forme de preuve. Cette identité, c’est la fonctionnalité.
2. L’anti-pattern « l’IA suggère, l’opérateur copie-colle »
Les boutons de quick-action opérateur (ceux qui disent Brouillon de réponse, Résumer le fil, Composer une relance) affichaient auparavant la sortie de l’IA dans un panneau latéral. L’opérateur copiait le texte, le collait dans le champ de réponse, éditait un peu, envoyait.
Trois choses ne vont pas avec ce pattern :
- La sortie structurée de l’IA (souvent avec des métadonnées d’intention, des sources, un niveau de confiance) était réduite à une chaîne par le copier-coller
- L’opérateur faisait les mêmes trois combinaisons de touches (Cmd-A, Cmd-C, clic-dans-l’éditeur, Cmd-V) des centaines de fois par jour
- Il n’y avait pas d’événement de gouvernance pour « l’opérateur a accepté la suggestion de l’IA » — seulement « l’opérateur a envoyé un message »
Le fix : les quick-actions invoquent désormais la recipe de bout en bout et streament le résultat directement dans l’éditeur. Les opérateurs éditent avant d’envoyer ou acceptent tel quel. Les actions à haut risque (toute action facturable, tout changement de statut) marquent toujours une pause de confirmation. Chaque quick-action est désormais une recipe versionnée, évaluable en A/B bake-off, sous le capot.
Le délai de première réponse sur les comptes en mode assisté a baissé de 38 % la première semaine. La métrique intéressante que nous n’attendions pas : la proportion d’éditions opérateur qui renforcent le brouillon IA (plutôt que de le réécrire) a augmenté. Le streaming dans l’éditeur permet aux opérateurs d’améliorer la sortie de l’IA au lieu de repartir de zéro. Mêmes portes de gouvernance, moins de clavier.
3. Le fichier JSON de voix de marque que nous recevions par e-mail
Si un client voulait ajuster sa voix de marque — phrases interdites, blocs de signature, cibles de longueur de phrase, variantes locales — le workflow était : le client nous envoyait une description par e-mail, nous la convertissions en profil JSON, nous déployions, le client attendait 24-48 heures.
Chaque étape de ce workflow était autrefois une fonctionnalité : « on le fait pour toi ». C’est devenu une friction au moment où les clients ont voulu A/B tester deux voix dans la même semaine.
Le fix : l’éditeur de voix de marque vit désormais à /portal/settings/brand-voice dans le portail client. Les clients éditent leur propre profil avec un aperçu live côte à côte (version actuelle vs. précédente, contre une entrée d’exemple). Chaque sauvegarde crée une nouvelle révision ; le rollback est en un clic ; le profil actif est injecté automatiquement dans chaque recipe orientée client.
La victoire moins évidente, c’est l’historique des versions. Les clients ne s’inquiètent plus de « si j’édite et que ça se dégrade, est-ce que je peux récupérer l’ancienne ? » parce que la réponse est oui, en deux clics. La réversibilité, c’était la friction, pas l’éditeur.
4. Le canal LINE qui prenait un appel d’appairage de 30 minutes pour être configuré
Connecter un canal LINE Messaging API à un compte JieGou demandait : le client crée un canal LINE, copie son channel ID et channel secret vers nous, nous nous connectons en SSH à un serveur pour enregistrer le webhook, nous répondons pour confirmer, puis le client teste.
Ça prenait 30 minutes quand tout allait bien. Quand quelque chose tournait mal (channel secret incorrect, mauvais format d’URL webhook, token expiré), deux jours.
Le fix : l’UI d’onboarding de canal à /portal/channels/line exécute tout le flow : coller le channel ID et le channel secret, l’UI valide, enregistre le webhook et confirme l’aller-retour avec un message synthétique. Les channel secrets sont scellés avec AES-256-GCM au repos. L’indicateur de santé du webhook montre la dernière livraison réussie, le compteur de retries et l’état actuel du canal LINE.
90 secondes, pas de SSH, pas de ticket de support. Le même flow interne qui propulse nos démos pré-vente à Taiwan et au Japon propulse maintenant l’onboarding self-service des clients. Nous nous sommes retirés du chemin critique de la connexion de canal sans retirer aucune des étapes de chiffrement ou de validation.
5. L’« entité Composio partagée » qui était une bombe d’isolation de tenant
Jusqu’à la semaine dernière, Composio (la couche de 250+ connecteurs d’outils tiers) utilisait un modèle d’entité partagée — les connexions étaient indexées par utilisateur, pas par compte JieGou. L’UI cachait ça. La couche worker respectait la frontière en pratique. Mais il n’y avait pas d’application architecturale qui disait les jetons HubSpot du compte A sont inaccessibles depuis les recipes du compte B. La frontière était une convention.
Pour un audit SOC 2 Type II, « convention » n’est pas une réponse.
Le fix : chaque compte JieGou provisionne désormais sa propre entité Composio à la première connexion d’intégration. Les jetons, scopes et états de connexion sont isolés par entity ID. Des tests de fuite cross-account ont été ajoutés à la suite standard — une action synthétique du compte A essayant de se résoudre vers une entité du compte B fait échouer le test, fait échouer le CI, bloque le merge.
Il n’y a pas d’UI pour ça. Il n’y a pas de démo. La seule chose qu’un client verra jamais, c’est le rapport de l’auditeur en fin d’année.
Le pattern compte : l’isolation appartient à la couche entité, pas à la couche UI. Les UI mentent. Les workers fail-open. Les données scopées par entité plus les tests cross-tenant imposés par CI sont la seule architecture qui survit à la question de l’auditeur « comment le prouvez-vous ? ».
6. L’approbation qui prenait 4 minutes à la manager pour s’ouvrir
L’IA propose une saisie de temps facturable. La manager reçoit un ping Slack qui dit « approbation requise ». Elle clique sur le lien, est redirigée vers le SSO, tape son mot de passe, fait son 2FA, atterrit sur la page d’approbation, lit l’entrée, clique Approuver. Quatre minutes. Faites maintenant ça 30 fois par jour pour 4 techniciens MSP.
Les 4 minutes n’étaient pas parce que quelqu’un était lent. Elles étaient parce que le chemin vers l’approbation exigeait une cérémonie d’identité complète pour ce qui était fonctionnellement un « pouce levé ».
Le fix : l’e-mail de la manager contient des boutons Approuver et Rejeter qui sont l’approbation. Chaque URL de bouton est un lien signé JWT, à durée limitée, à usage unique, lié à l’ID d’approbation spécifique et à l’e-mail de l’approbateur. Idempotent (cliquer Approuver deux fois poste une fois). Équivalent à l’auditeur (même forme approval_event ; le champ point d’entrée lit email_button pour le reporting de gouvernance). Le rejet ouvre un formulaire d’une ligne pour capturer la raison.
La cryptographie a fait le travail que SSO + 2FA faisait avant. La confiance ne s’est pas affaiblie ; elle a été relocalisée. Le lien signé est un équivalent de credential pour une décision unique.
Le pattern : confiance + preuve + la bonne frontière
Relisez ces six. Le pattern est constant :
- Portes Concierge : faire confiance à l’intention de l’opérateur ; capturer la preuve quand même (chaque action Concierge émet le même
audit_event) - Quick actions : faire confiance à l’édition de l’opérateur ; la recipe sous-jacente est toujours versionnée, évaluée, scorée en qualité
- Éditeur de voix de marque : faire confiance au client pour écrire sa propre voix ; chaque sauvegarde est une révision versionnée avec rollback
- Credentials LINE : faire confiance au chiffrement du channel secret (AES-256-GCM au repos, aller-retour validé à la sauvegarde) au lieu de faire confiance à la cérémonie SSH-vers-serveur
- Composio scopé par compte : faire confiance à la frontière entité (imposée architecturalement, testée par CI) au lieu de faire confiance à l’UI
- Approbations inbox : faire confiance au JWT (signé, à durée limitée, à usage unique) au lieu de faire confiance au chemin SSO-puis-2FA
Dans chaque cas, la confiance ne s’est pas affaiblie — elle s’est relocalisée vers une couche où la friction est plus basse. Certaines de ces confiances (cryptographie, données scopées par entité) sont objectivement plus fortes que ce qu’elles ont remplacé (cérémonie SSH, convention UI). Le log d’audit s’est enrichi, pas appauvri.
C’est ce qu’exige réellement la « gouvernance invisible » : à chaque endroit où un opérateur ou un client touche la plateforme, vous devez demander est-ce que la confiance peut vivre quelque part avec moins de friction tout en produisant la même preuve ? Quand la réponse est oui, vous livrez. Quand la réponse est non — vous gardez la friction, mais vous devez une explication dans le doc de design.
Ce que ça change dans notre planification
Après la semaine dernière, deux choses dans notre processus de planification sont différentes :
- Chaque item de roadmap a maintenant un champ « couche de confiance ». Où vit la confiance pour cette fonctionnalité ? Cryptographie ? Frontière entité ? Intention de l’opérateur ? Log d’audit ? Si la réponse est « l’UI », on redessine.
- Chaque histoire de friction client est reposée comme une question de relocalisation de confiance. Pas « comment rendre ça plus rapide ? » mais « où vit la confiance actuellement, et peut-elle déménager vers une couche avec moins de friction ? »
Ce ne sont pas des idées nouvelles en sécurité informatique. (Lisez Saltzer & Schroeder, 1975 si vous ne l’avez pas fait.) Mais les appliquer à chaque workflow opérateur, semaine après semaine, c’est ainsi qu’une plateforme IA réellement agréable à utiliser se construit. Le slogan « gouvernance invisible » est le résultat. Le travail, c’est de payer la facture d’ingénierie, livraison après livraison.
Six étaient dues la semaine dernière. Nous nous attendons à en payer six de plus la semaine prochaine.
Commencez gratuitement → — ou si vous voulez voir à quoi ressemblent huit mois de paiement de cette facture, réservez une démo des services managés et nous vous montrerons le log d’audit d’un compte qui est gouverné-et-invisible depuis le jour un.