The SamurAI · en production depuis mars 2026
Dawn
Un agent autonome de gestion de projet où rien n'est écrit avant qu'un humain ne l'approuve.
- Mon rôle
- Conception et développement de l'ensemble du système
- Période
- 2026, en production depuis mars
Technologies
- Python
- SurrealDB
- Redis
- OpenRouter
- Llama
- Microsoft Graph
- AWS
- Linux
- GitHub Actions
- Logfire
- Langfuse
Sur le CV
- Conçu et développé Dawn, un agent IA autonome de gestion de projet, mis en production en mars 2026 : transforme les réunions enregistrées en tâches (responsable, priorité, échéance), avec validation humaine avant toute écriture dans Microsoft Planner.
- Conçu sa mémoire en graphe : un graphe de connaissances SurrealDB avec RAG hybride (recherche vectorielle et pondération temporelle) et cache de contexte Redis (CAG), intégré à l'API Microsoft Graph.
- Conçu sa couche de gouvernance et de sécurité : contrôle d'identité, politiques par agent, messages entrants vérifiés par HMAC, journal d'audit, seuil de confiance et données sensibles routées vers un modèle Llama local.
- Développé un routage multi-modèles via OpenRouter avec repli automatique ; déployé sur AWS EC2 sécurisé avec CI/CD GitHub Actions et observabilité via Logfire et Langfuse.
Le problème
Une petite équipe de conseil enregistre beaucoup de réunions. Les engagements pris ne se transformaient pas de façon fiable en travail suivi : quelqu'un devait lire la transcription, décider qui fait quoi, et le saisir dans Microsoft Planner. Le suivi dépendait de la mémoire.
La demande n'était pas « automatiser la gestion de projet ». Elle était plus étroite et plus dure : faire entrer les bonnes tâches dans Planner, avec le bon responsable et la bonne date, sans jamais laisser une IA écrire quelque chose que personne n'a vérifié.
Ce que j'ai construit
Dawn lit les transcriptions, rassemble le contexte d'équipe nécessaire, extrait des tâches proposées avec responsable, priorité, échéance et score de confiance, et les envoie par e-mail à deux responsables. Ils répondent APPROVE ou REJECT. Alors seulement Dawn crée les tâches dans Planner, enregistre ce qui s'est passé dans sa mémoire en graphe, et commence à relancer les personnes quand le travail stagne.
Microsoft bloquait les messages directs applicatifs dans Teams ; l'e-mail est donc devenu le canal de validation. Livré des semaines plus tôt qu'en attendant un accès administrateur, et les responsables l'ont adopté.
Comment ça marche
Défile tout seul. Cliquez sur une étape pour faire pause.
Décisions et compromis
- Validation humaine avant toute écriture, plutôt que création automatique au-dessus d'un seuil
- La confiance devait venir d'abord, et le rayon d'impact d'une mauvaise tâche devait être nul. La règle livrée : rien n'atteint Planner sans réponse.
- CAG et RAG, pas l'un ou l'autre
- Les petits faits stables sont en cache dans Redis. L'historique volumineux est recherché. Deux problèmes, deux outils.
- Reclassement hybride plutôt que top-k naïf
- La similarité seule laissait de vieilles réunions dépasser les récentes. Similarité plus récence, avec seuil strict.
- SurrealDB plutôt qu'une base graphe séparée plus un store vectoriel
- Documents, arêtes et vecteurs dans un moteur : un schéma, un client, une sauvegarde. Les arêtes sont de première classe.
- Appels API directs plutôt qu'un framework d'agents
- Flux de contrôle explicite, appels IA lisibles, état visible dans Redis et SurrealDB.
- Modèles comme alias derrière un routeur
- Changer de fournisseur tient en une ligne. Le contenu sensible est forcé vers un modèle local.
- Archiver à 90 jours plutôt que supprimer
- L'historique a de la valeur et le stockage est bon marché.
Gouvernance
- Contrôle d'identité
- Seuls les expéditeurs du domaine de l'entreprise déclenchent des actions. Les externes sont redirigés sans données.
- Messages entrants signés
- Chaque requête webhook Teams entrante est vérifiée par HMAC-SHA256. Les signatures invalides sont rejetées.
- Routage des données sensibles
- Des mots-clés liés à des contenus réglementés ou sensibles forcent un modèle local et signalent l'élément.
- Journal d'audit
- Chaque proposition garde son raisonnement, sa confiance, qui l'a résolue et quand. Les destinataires ne voient jamais les scores, les noms de modèles ou les identifiants.
- Hôte durci
- Utilisateur de service non root, secrets hors dépôt, volume chiffré, IAM de moindre privilège, SSH par clé, correctifs automatiques. Déployé par GitHub Actions ; tracé dans Logfire et Langfuse.
Ce que j'ai appris
- Chaque bug de production était un classique des systèmes distribués : doublons, boucle sur soi-même, mises à jour perdues. La solution était l'idempotence, pas un meilleur prompt.
- La validation humaine est une machine à états (en attente, approuvée, refusée, doublon, bloquée) et mérite autant de soin que l'appel au modèle.
- Un webhook qui doit répondre en cinq secondes et un traitement plus long sont deux programmes différents. Les séparer a supprimé toute une classe de plantages silencieux.
- La meilleure interface de validation était celle que les responsables utilisaient déjà. L'e-mail a battu l'interface sur mesure.
Construit dans un dépôt d'entreprise privé. Noms, identifiants et références internes sont volontairement omis.
Étude de cas suivante
Collaboris