Ingénierie d'agents sur spécifications
Quand aucun agent existant ne répond au besoin, on en conçoit un. C'est la famille la plus exigeante, et celle qui définit notre métier.
De quoi il s'agit
Fabriquer un agent IA est devenu accessible. Les modèles sont disponibles, les bibliothèques sont ouvertes, une démonstration se monte en quelques jours. C'est précisément pour cette raison que la démonstration ne vaut plus rien.
Ce qui reste difficile, c'est de faire tenir un agent en production, sur des données imparfaites, dans un environnement qui change, avec des utilisateurs qui ne sont pas ingénieurs. L'écart entre un prototype qui marche au bureau et un système qui tourne six mois sur un site client est considérable.
C'est là qu'est notre métier.
L'architecture d'un agent
Quatre couches, et la performance dépend de la plus faible.
Un moteur de perception qui transforme un flux, un document ou un message en observations. Une logique métier qui encode vos règles. Un mécanisme de décision robuste au bruit, avec son seuil de confiance. Un canal d'action qui déclenche quelque chose d'utile.
La plupart des projets échouent sur les deuxième et troisième couches, pas sur la première.
Ce qui distingue un développement sur spécifications
Il ne part pas d'un produit à configurer, mais d'un problème à résoudre. Cela suppose d'observer le processus réel avant d'écrire une ligne de code, d'identifier le point exact où l'intelligence crée de la valeur, et de concevoir une architecture qui tiendra dans votre environnement.
Chaque déploiement est conteneurisé et versionné. On sait quelle version tourne sur quel site, et on peut revenir en arrière. Sans cela, une mise à jour qui dégrade la performance devient impossible à diagnostiquer.
Quand c'est justifié — et quand ça ne l'est pas
Justifié quand le besoin est propre à votre métier, quand plusieurs sources doivent converger, ou quand le contexte impose une architecture particulière.
Pas justifié quand un agent du Pack couvre déjà le besoin, ou quand une règle simple suffirait. Nous le disons au diagnostic : un développement sur mesure pour un besoin standard est un gaspillage, et un client qui le découvre après coup ne revient pas.
┌─ PERCEPTION ──────────────────────────────┐
│ flux · document · message · base │
│ YOLO / OCR-IDP / embeddings / connecteurs│
└───────────────┬───────────────────────────┘
↓
┌─ LOGIQUE MÉTIER ──────────────────────────┐
│ règles explicites · seuils · tolérances │
│ vérifiables, testables, versionnées │
└───────────────┬───────────────────────────┘
↓
┌─ DÉCISION ────────────────────────────────┐
│ score de confiance → seuil │
│ ≥ seuil : agit | < seuil : transmet │
└───────────────┬───────────────────────────┘
↓
┌─ ACTION ──────────────────────────────────┐
│ n8n · API REST · webhooks · notification │
│ idempotence · file d'attente · reprise │
└───────────────────────────────────────────┘Sous le capot
La ligne de partage entre modèle et règle est le premier choix d'architecture. Le modèle traite ce qui demande de l'interprétation ; la règle traite ce qui se vérifie. Une addition ne s'infère pas.
Le déploiement est conteneurisé et versionné. Chaque site exécute une image identifiée, on sait quelle version tourne où, et un retour arrière est possible. Sans cela, une mise à jour qui dégrade la performance devient impossible à diagnostiquer.
Le fine-tuning est l'exception, pas la règle. Pour transmettre de la connaissance métier, le RAG fait mieux : mise à jour immédiate, réponse sourçable, coût marginal. Le fine-tuning ne devient pertinent que sur trois cas — un format de sortie strict, un vocabulaire métier que le modèle interprète mal, ou un modèle plus petit à faire tourner en local sur une tâche répétitive.
Deux principes non négociables sur la couche d'action. L'idempotence : rejouer une opération ne produit jamais de doublon. La file d'attente avec reprise : une indisponibilité met l'opération en attente, elle n'est ni perdue ni exécutée à moitié.
Parlons de votre projet.
Trente minutes, gratuit et sans engagement.
Sous le capot — l'ingénierie sur spécifications
Fabriquer un agent IA est devenu accessible : les modèles sont disponibles, une démonstration se monte en quelques jours. C'est précisément pour cette raison que la démonstration ne vaut plus rien. Ce qui reste difficile, c'est de faire tenir un agent en production, sur des données imparfaites, dans un environnement qui change, avec des utilisateurs qui ne sont pas des ingénieurs.
Notre approche technique
Un agent est un assemblage de quatre couches, et sa performance dépend de la plus faible : un moteur de perception qui transforme un flux en observations, une logique métier qui encode vos règles, un mécanisme de décision robuste au bruit, un canal d'action qui déclenche quelque chose d'utile.
La plupart des projets échouent sur la deuxième et la troisième couche, pas sur la première. Détecter une personne est un problème résolu. Décider si cette détection mérite une alerte à 3 h du matin dans cette zone-la, en tenant compte du fait qu'un agent de sécurité y passe habituellement, ne l'est pas — et cela ne se résout pas avec un modèle plus gros.
La calibration se fait sur site, jamais en laboratoire. Les seuils de confiance, les durées de confirmation, les zones d'intérêt se règlent sur les conditions réelles : la lumière de ce couloir, la hauteur de cette caméra, le rythme réel de ce point de vente. Un système livré avec des paramètres par défaut produit des faux positifs jusqu'à ce que plus personne ne regarde les alertes.
Chaque déploiement est conteneurisé et versionné. On sait quelle version d'un modèle tourne sur quel site, et on peut revenir en arrière. Sans cela, une mise à jour qui dégrade la performance devient impossible à diagnostiquer.