Ma première expérience professionnelle s’est déroulée chez Cygogn, pendant ma deuxième année de BUT informatique. Cygogn est une jeune entreprise qui construit des produits IA pour traiter des flux métier reçus par mail : commandes, devis, factures, demandes client, puis les relier aux systèmes internes des organisations.
J’y suis arrivé au moment où l’entreprise faisait évoluer son produit : quitter progressivement un outil centré sur le tri de mails pour construire une plateforme agentique plus large. Dans une équipe technique très réduite, mon rôle a été de transformer des besoins encore mouvants en livrables concrets : site public, front office, connecteur métier et agent d’intégration de bons de commande.
Ce cadre m’a obligé à travailler autrement que dans un projet universitaire. Les priorités pouvaient évoluer après une discussion commerciale, une contrainte technique ou un retour d’essai sur un flux pilote ; chaque changement devait donc passer par un cycle plus professionnel : développement local, vérification en intégration, puis mise en production quand le risque était maîtrisé.
Construire l’interface pendant que le produit se stabilise
La brique la plus structurante a été le front office. Le besoin initial tenait en une formule assez large : donner aux clients de la visibilité sur leurs flux. Il a fallu transformer cette intention en écrans concrets : indicateurs, volumes traités, taux d’automatisation, règles métier, boîtes connectées et validation de commandes.
J’ai choisi de développer l’interface directement en Next.js avec des données fictives, plutôt que de passer par une maquette jetable. Cette maquette vivante permettait de présenter une version manipulable tous les quatre à cinq jours, d’obtenir des retours de l’équipe, puis de converger rapidement vers une interface que l’on pourrait ensuite brancher au serveur.
Le front office ne se limitait pas au tableau de bord. Il devait aussi rendre lisibles les règles qui guident le traitement des messages. Cette partie m’a appris à faire évoluer l’interface en fonction de contraintes découvertes côté données : certains affichages semblaient naturels dans la maquette, mais devaient être ajustés une fois reliés au système réel.
Dessiner des outils que l’agent peut réellement utiliser
Une autre brique de cette première expérience portait sur un connecteur métier pour un client pilote. L’objectif était de permettre à un agent IA de consulter un système externe afin de retrouver la bonne information, puis d’agir sur un mail avec plus de contexte.
La difficulté n’était pas seulement de consommer une API. Il fallait concevoir un contrat d’outils MCP que l’agent puisse exploiter correctement : paramètres, noms, retours structurés, quantité d’information exposée. Les premiers essais ont montré que la forme du connecteur conditionnait directement la capacité de l’agent à aboutir.
J’ai donc avancé par petites corrections : reprendre les essais où l’agent butait, identifier si le problème venait de la donnée renvoyée, d’un paramètre ambigu ou d’un retour trop pauvre, puis ajuster l’outil concerné. Le connecteur a ensuite été déployé en serverless sur Scaleway, avec une configuration décrite en Terraform et une séparation stricte des secrets.
Automatiser sans retirer le contrôle humain
Le chantier le plus représentatif de la plateforme agentique a été l’intégration de bons de commande. Le problème est très concret : dans beaucoup d’entreprises, un bon de commande arrive en PDF par mail, puis quelqu’un ressaisit les informations dans l’ERP. Entre le PDF et l’ERP, il faut transformer un document peu structuré en données métier fiables, assez propres pour être vérifiées puis intégrées. L’agent devait lire le document, retrouver le client, l’adresse de livraison et les articles, puis préparer une commande exploitable.
Le point important n’était pas seulement l’extraction. Nous avons conçu le parcours pour que l’agent propose une commande, mais ne déclenche pas l’écriture dans l’ERP sans validation humaine. Ce choix d’architecture répond à une contrainte produit essentielle : automatiser le travail répétitif tout en gardant un contrôle explicite sur l’action qui engage le système du client.
Sur cette mission, le travail d’équipe a surtout porté sur le cadrage de l’agent et sur la recherche d’articles. Les désignations présentes dans les bons de commande ne correspondent presque jamais exactement aux fiches ERP ; nous avons donc retenu une recherche par embeddings avec repli lexical.
Ce que cette première expérience a réellement déplacé
À la fin de cette première expérience professionnelle, plusieurs briques étaient en production ou proches de l’être : le site public était en ligne sur www.cygogn.com, le front office était utilisé par l’équipe commerciale, le connecteur métier tournait sur de vrais flux, et l’agent de bons de commande était prêt pour une démonstration client. Ce sont ces résultats qui donnent du poids au projet : ils ne restent pas au niveau d’un exercice ou d’une preuve de concept isolée.
Le changement le plus important pour moi a été la discipline de livraison. Au début, j’avais tendance à regrouper trop de modifications. J’ai appris à travailler par briques plus petites : une évolution ciblée, testée en intégration, puis livrée quand elle était assez claire. Cette méthode réduit le risque, mais elle force surtout à rendre le travail visible plus tôt.