Point clé
Chrono a remplacé la fonction IA purement consultative d'une plateforme de créateurs par un agent intégré qui modifie réellement la page de l'utilisateur, en ligne avec de vrais utilisateurs en moins de trois semaines, avec 398 tests automatisés au vert et un agent soumis exactement aux mêmes permissions que l'utilisateur.
Une plateforme grand public pour créateurs avait déjà une fonction IA. Elle disait aux utilisateurs quoi faire avec leur page, mais ne pouvait rien faire elle-même, et oubliait la conversation dès qu’elle se terminait. Chrono l’a remplacée par un agent intégré à l’administration des créateurs, qui fait les changements lui-même. De vrais utilisateurs l’avaient en main en moins de trois semaines. Si vous hésitez à laisser un agent IA toucher aux données de vos clients, voici comment nous avons rendu ça sécuritaire.
Qu’est-ce qui clochait avec la fonction IA d’origine ?
Elle conseillait, puis s’arrêtait là. Un créateur demandait comment améliorer sa page, recevait une liste de suggestions, puis devait faire chaque changement à la main. Elle n’avait pas de mémoire non plus : chaque session repartait de zéro.
C’est le piège dans lequel tombent la plupart des « assistants IA » intégrés aux produits. Les utilisateurs ne veulent pas de conseils sur leur page. Ils veulent que leur page soit réglée.
Que fait le nouvel agent ?
Il agit sur la page du créateur, directement dans l’administration. Le créateur formule sa demande en langage courant et l’agent fait le travail :
- Créer, modifier et réordonner des liens
- Archiver les liens dont il ne veut plus
- Fixer des objectifs et suivre leur progression
Chaque action est un outil typé dont les entrées sont validées. L’agent en a 17, et il ne peut rien faire en dehors de cette liste.
Comment laisser un agent modifier des données d’utilisateurs en toute sécurité ?
On fait en sorte que l’agent agisse en tant qu’utilisateur. C’est la décision centrale de ce projet, et tout le reste en découle.
L’interface de l’application et l’agent passent par la même couche de requêtes. L’accès est contrôlé par la sécurité au niveau des lignes (Row Level Security) de Postgres : des règles dans la base de données qui décident, ligne par ligne, ce que chaque utilisateur connecté peut lire ou modifier. Comme l’agent passe par ces mêmes règles, il ne peut jamais atteindre des données que l’utilisateur ne pourrait pas atteindre en cliquant dans l’interface. Il n’existe aucune clé de service dans le système, donc aucune porte dérobée à faire fuiter.
Trois autres décisions ont gardé le risque bas :
Archiver, jamais supprimer. L’agent ne peut rien effacer définitivement. Chacune de ses actions peut être annulée.
Commencer petit. La première version est sortie avec un petit ensemble d’actions que nous pouvions tester de bout en bout. Nous en avons ajouté seulement quand nous avions la preuve qu’il en fallait.
Les tests font foi. Rien n’était fusionné sans une suite de tests au vert. Au lancement, c’était 398 tests automatisés, et chaque pull request avait son propre déploiement de prévisualisation pour valider les changements dans un vrai environnement avant la mise en production.
Quelle est l’architecture ?
La passerelle IA se place entre l’agent et le fournisseur de modèles, ce qui permet de changer de modèle sans toucher au code du produit.
Que ferions-nous autrement ?
Geler avant les tests utilisateurs. Au début, nous poussions des changements le jour même dans l’environnement de test pendant que des utilisateurs s’en servaient, et c’était fragile. Maintenant, nous gelons une branche et la préparons avant chaque ronde de tests utilisateurs. De petites pull requests empilées gardent la cadence élevée sans déstabiliser la branche principale.
Qu’est-ce que ça change pour votre produit ?
Si votre fonction IA se contente de donner des conseils, le saut vers un agent qui agit est plus petit qu’il n’y paraît. Le plus difficile, ce n’est pas le modèle. C’est le contrôle d’accès, la réversibilité et les tests, et ce sont des décisions d’ingénierie ordinaires qu’on peut prendre dès le départ.
Voyez notre approche dans à quoi ressemble vraiment l’architecture d’un agent IA en production, ou passez directement au développement d’agents IA. Si vous préférez d’abord cadrer une fonctionnalité précise, commencez ici.
Questions fréquentes
Comment Chrono a-t-elle livré un agent IA à de vrais utilisateurs en moins de trois semaines ?
En gardant la première version restreinte. L’agent a été lancé avec un petit ensemble d’actions testables de bout en bout, il passait par la couche de données existante de l’application plutôt que par une nouvelle, et chaque changement était livré avec une suite de tests au vert et un déploiement de prévisualisation.
Comment empêcher un agent IA d’accéder à des données auxquelles il ne devrait pas avoir accès ?
En le faisant agir comme l’utilisateur connecté et en le soumettant aux mêmes vérifications de permissions que l’interface. Sur cette plateforme, la sécurité au niveau des lignes de Postgres est le seul contrôle d’accès pour les deux, et il n’existe aucune clé administrateur que l’agent pourrait utiliser pour la contourner.
Que se passe-t-il si l’agent fait une mauvaise modification ?
Elle peut être annulée. L’agent peut archiver mais jamais supprimer, donc le créateur peut défaire chacune de ses actions.
