Edecán

L’agent de support relié à vos outils

Un service Go autonome pour répondre aux utilisateurs et transmettre les demandes qui exigent une intervention humaine

« Edecán » signifie « aide de camp » en espagnol.

Les équipes de support reviennent souvent sur les mêmes questions. Elles cherchent une information dans la documentation, reformulent une réponse déjà donnée, puis recopient le contexte dans un ticket lorsque le problème demande une intervention.

Edecán prend en charge cette première étape. Il répond dans une interface de discussion, consulte les outils que vous lui avez autorisés à utiliser et peut préparer un ticket à partir de la conversation.

Ce que fait Edecán

Edecán est un agent de support configurable. Il peut :

  • répondre aux questions des utilisateurs ;
  • appeler des outils externes pendant la conversation ;
  • adapter ses instructions au projet et au profil de l’utilisateur ;
  • transmettre la demande à l’équipe de support sous la forme d’un ticket Gitea ou GitHub ;
  • conserver l’historique des échanges et le lien avec le ticket créé.

Le backend de tickets reste la référence pour le suivi de la demande. Edecán ne cherche pas à le remplacer.

L’application est écrite en Go et rend ses pages côté serveur. Elle ne repose pas sur une SPA.

Configurer les agents

Chaque agent se configure en YAML. La configuration indique notamment le modèle à utiliser, ses instructions et les outils MCP auxquels il peut accéder.

Plusieurs agents peuvent cohabiter dans une même installation. Un projet peut, par exemple, proposer un agent généraliste et un agent technique relié à des outils supplémentaires.

Edecán peut aussi demander un effort de raisonnement aux modèles qui prennent cette option en charge. Si le fournisseur renvoie un contenu de raisonnement, l’interface l’affiche dans une section repliable. Le résultat dépend donc du modèle et du fournisseur choisis.

Relier la documentation et les outils métier avec MCP

Edecán prend en charge le Model Context Protocol, ou MCP. Un agent peut ainsi consulter une documentation interne, interroger une API métier ou utiliser un autre outil exposé par un serveur MCP. Il est particulièrement pensé pour fonctionner avec une ou plusieurs instances Amoxtli.

Deux modes de connexion sont disponibles :

  • Streamable HTTP, pour joindre un serveur distant et lui transmettre des en-têtes configurables ;
  • stdio, pour lancer un serveur MCP comme sous-processus sur la machine qui héberge Edecán.

Les modèles de configuration peuvent inclure des données liées à la session. Un serveur MCP peut s’en servir pour limiter les ressources accessibles à chaque conversation.

Edecán borne aussi les appels successifs aux outils et leur durée. Ces limites évitent qu’une génération reste bloquée sur un outil indisponible ou qu’un agent enchaîne les appels sans répondre.

Créer un ticket Gitea ou GitHub

Lorsqu’une discussion doit passer au support, Edecán prépare un brouillon à partir de la conversation.

Si plusieurs modèles de tickets sont configurés, l’agent choisit celui qui correspond le mieux à la demande. Il peut ainsi distinguer un rapport de bug d’une demande d’évolution, puis remplir les sections prévues.

Les modèles peuvent être traduits et associés à des étiquettes. Les pièces jointes sont envoyées au backend de tickets et rattachées au ticket ou au commentaire concerné. Edecán peut utiliser un stockage local ou compatible S3 pour les médias produits pendant les conversations.

Une fois le ticket créé, Gitea ou GitHub reste la source de vérité. Edecán conserve l’historique du chat et la référence du ticket afin de relier les deux échanges.

Edecán est par conception extensible et d’autres plateformes de ticketing seront intégrées au fur et à mesure des besoins.

Authentifier les utilisateurs

Edecán accepte plusieurs méthodes d’authentification :

  • OIDC ou OAuth2 avec un fournisseur compatible ;
  • lien de connexion envoyé par courriel.

Les liens de connexion sont à usage unique et expirent après une durée configurable. La réponse affichée ne révèle pas si une adresse est connue. Cela évite de transformer la page de connexion en outil de recherche d’adresses.

L’accès aux projets et le rôle de l’utilisateur peuvent dépendre de règles appliquées à son adresse électronique. Un utilisateur accède à ses propres sessions. Les membres du support disposent d’une vue adaptée au suivi des conversations du projet.

Adapter les réponses avec les personas

Les personas permettent d’ajouter des instructions à l’agent selon l’utilisateur et le projet consulté. Elles modifient le prompt système envoyé au modèle.

Chaque persona contient :

  • un ou plusieurs filtres appliqués à l’adresse électronique de l’utilisateur ;
  • une liste facultative de projets ;
  • des instructions ajoutées au prompt de l’agent.

Si aucun projet n’est indiqué, la persona s’applique à tous les projets. Si plusieurs personas correspondent au même utilisateur, Edecán les applique dans leur ordre de déclaration. Leurs instructions se cumulent.

Une équipe peut, par exemple, demander à l’agent de fournir davantage de détails techniques aux membres internes, ou d’adapter son vocabulaire aux clients d’un produit donné.

personas:
  - name: equipe-interne
    filters:
      - "*@example.com"
    projects:
      - produit-a
    prompt: |
      L'utilisateur appartient à l'équipe interne.
      Tu peux employer le vocabulaire technique du projet
      et proposer des étapes de diagnostic détaillées.

Une interface en français, anglais et espagnol

L’interface est disponible en français, en anglais et en espagnol. Edecán choisit la langue à partir du paramètre lang, du cookie enregistré ou de l’en-tête Accept-Language.

Les traductions sont embarquées dans le binaire.

L’agent répond dans la langue de la conversation. Lorsqu’il utilise un outil, ses instructions peuvent lui demander de conserver la langue de la source interrogée. C’est utile pour rechercher des termes exacts dans une documentation qui n’existe que dans une seule langue.

Adapter Edecán à chaque projet

La configuration permet de modifier plusieurs éléments.

  • Le nom affiché dans l’interface se règle avec branding.title.
  • Chaque projet peut avoir une page d’accueil rédigée en Markdown et traduite.
  • Les personas associent certains utilisateurs à des instructions supplémentaires, selon leur adresse et le projet consulté.
  • Les projets peuvent proposer plusieurs agents et plusieurs modèles de tickets.

Cette configuration permet, par exemple, de donner des consignes différentes aux équipes internes et aux clients, sans déployer une seconde application.

Déploiement

ÉlémentFonctionnement
ApplicationUn binaire Go pour le serveur Edecán
Base de donnéesSQLite embarqué avec un pilote Go sans CGO
InterfaceHTML rendu côté serveur avec templ
ConfigurationFichier YAML et secrets lus depuis les variables d’environnement
RéponsesDiffusion progressive vers le navigateur
LicenceGNU AGPL version 3

Le serveur Edecán tient dans un seul binaire. Son fonctionnement dépend néanmoins des services que vous configurez, notamment le fournisseur de modèles, le backend Gitea ou GitHub, le fournisseur d’identité et les éventuels serveurs MCP.

Lancer le projet

Préparez le fichier de configuration et les variables d’environnement :

make config.yaml
# Créez ensuite le fichier .env avec les secrets utilisés par config.yaml.

Lancez le serveur :

make run

Pendant le développement, la commande suivante régénère les fichiers templ, reconstruit l’application et relance le serveur après chaque modification surveillée :

make watch

La compilation produit un binaire dans ./bin/edecan :

make build

Pour quels usages ?

Edecán convient surtout aux équipes qui utilisent déjà Gitea ou GitHub pour suivre leurs demandes et qui veulent ajouter un premier niveau de réponse relié à leur documentation.

Il peut aussi servir de point d’entrée vers des outils internes grâce à MCP. L’intérêt est concret lorsque les mêmes questions reviennent souvent, mais que certaines demandes doivent encore être reprises par une personne avec tout leur contexte.

Edecán ne remplace pas l’équipe de support. Il traite les demandes qu’un agent peut résoudre et prépare le passage à un humain pour les autres.

Code source

Edecán est distribué sous licence GNU AGPL version 3. Le code peut être consulté, modifié et déployé sur votre propre infrastructure.

Voir le dépôt Edecán sur GitHub