InternGuide AI répond aux questions des stagiaires et collaborateurs sur la documentation interne d'une entreprise, avec toujours une source citée. Simple sur le papier. Ce qui suit, c'est ce qui s'est vraiment passé entre le prototype qui marche en local et un produit que de vraies personnes utilisent tous les jours sur Slack.
Le piège du "10/10 aux tests"
Premier jalon : 10 cas de test rejoués contre le retrieval réel, 10 succès. Tentant de s'arrêter là. Sauf que ces tests étaient à un seul tour de conversation — pas représentatif d'un vrai échange Slack, qui se fait sur plusieurs messages. Il a fallu construire la vraie récupération d'historique de conversation avant de pouvoir dire que l'agent fonctionnait "en vrai".
Slack : la partie qui n'était pas dans le plan
Trois problèmes réels, aucun n'était dans la documentation officielle :
- Le mode Socket Mode de Slack, activé par défaut, qui redirige silencieusement toute la livraison des messages vers une connexion différente de celle configurée — l'app semblait cassée alors qu'elle était juste mal branchée
- L'onglet Messages de l'App Home désactivé par défaut, qui bloque tout message privé avec l'erreur "Sending messages to this app has been turned off"
- Un bug plus subtil : l'agent répétait sa phrase d'accueil à chaque message, même en pleine conversation, parce que l'historique était codé en dur à vide dans un nœud hérité d'une version de test à un seul tour
Aucun de ces trois bugs n'apparaît en testant "à la main" une seule fois. Ils ne sont sortis qu'en usage réel, répété.
L'infrastructure, ou pourquoi un tunnel de test n'est pas un tunnel de production
Pour exposer l'instance n8n locale à Slack, premier réflexe : un tunnel "quick" Cloudflare, gratuit, sans compte. Il a tenu deux heures avant de se déconnecter. Passage à un tunnel nommé, durable — stable, mais qui ne redémarre pas automatiquement après un redémarrage machine. Tentative de le transformer en service Windows : échoue silencieusement, le compte système n'a pas le même accès réseau que la session utilisateur. Contournement final : une tâche planifiée qui démarre à l'ouverture de session plutôt qu'un service — moins élégant sur le papier, mais c'est la seule solution qui marche vraiment sur ce poste.
Le rate limiting : quand le test lui-même ment
Une fois l'application web en ligne, ajout d'une protection contre les abus (10 requêtes par minute par IP). Premier test : 12 requêtes envoyées à la suite, aucune bloquée. Bug ? Non — chaque requête passe par le modèle et prend plusieurs secondes, donc 12 requêtes séquentielles s'étalent largement au-delà de la fenêtre d'une minute.
200 200 200 200 200 200 200 200 200 200 429 429 429 429 429
Ce que ça dit de la méthode
Rien de tout ça ne se serait vu en relisant le code ou la documentation. Un agent IA qui fonctionne, ce n'est pas un agent qui répond juste à une question isolée — c'est un agent testé en conditions réelles, avec de vrais canaux, de vraies conversations à plusieurs tours, et une vraie charge. La discipline qui a fait la différence ici : ne jamais déclarer une fonctionnalité "faite" sans l'avoir vue marcher en réel, jusqu'au bout.