La frontière de décision
Choisissez un pipeline déterministe lorsque les étapes et la vérité terrain sont connues. Choisissez un agent lorsque le système doit sélectionner et ordonnancer ses actions de manière dynamique — et uniquement si cette flexibilité crée suffisamment de valeur pour justifier les risques, la latence et le coût d’évaluation supplémentaires.
Une tâche circonscrite telle que la transcription, la classification, l’extraction ou la recherche documentaire relève normalement d’un pipeline. Une recherche en plusieurs étapes, une investigation intersystèmes ou le traitement d’exceptions peuvent justifier un agent, car le bon chemin dépend alors des observations intermédiaires.
| Signal de décision | Pipeline | Agent |
|---|---|---|
| Chemin d’exécution | Connu ou énumérable | Dépend des résultats intermédiaires |
| Vérité terrain | Exacte ou directement mesurable | Heuristique ou fondée sur le résultat |
| Latence et coût | Prévisibles | Variables et dépendants des itérations |
| Effets de bord | Étapes explicites du flux de travail | Doivent être autorisés séparément |
| Évaluation | Tests de régression par étape | Évaluation de la trajectoire, des outils et du résultat |
Contrôles minimaux pour la production
Exposez des opérations nommées, propres à chaque domaine et dotées de schémas validés. Ne fournissez pas au modèle un client HTTP ou de base de données générique.
Prévoyez un chemin d’achèvement dédié, un plafond d’itérations, un budget temps et des conditions d’arrêt déterministes.
Le modèle propose une action ; une politique déterministe évalue l’identité, le périmètre, la cible et l’état courant avant toute exécution.
Limitez et étiquetez les résultats des outils afin de réduire la saturation du contexte, les divulgations accidentelles et la contamination par des instructions.
Consignez les décisions du modèle, les noms d’outils, les arguments normalisés, les décisions de politique et les effets de bord afin de pouvoir reconstituer l’exécution.
Testez séparément la sélection des outils, la validité des arguments, le respect des politiques, le comportement de terminaison et le résultat final de la tâche.
Modes de défaillance à éliminer dès la conception
- Boucles non bornées : le système continue d’appeler des outils sans convergence ni plafond strict.
- Confusion de mandataire : le modèle hérite des droits étendus de l’utilisateur au lieu de recevoir une autorisation limitée à l’opération.
- Utilisation d’outils induite par injection d’instructions : un contenu récupéré influence une action privilégiée sans passer par une frontière de politique déterministe.
- Achèvement partiel silencieux : l’agent annonce un succès alors que des étapes ou validations obligatoires restent inachevées.
- Décisions impossibles à reconstituer : les journaux capturent le raisonnement textuel, mais omettent les arguments exacts des outils et la décision de politique.
Règle opérationnelle
Un agent autorisé à redémarrer un service ne doit pas acquérir pour autant la capacité de le supprimer. Les limites de capacité relèvent d’une politique exécutable, pas des instructions système.
Comment évaluer l’architecture
- Établissez des références déterministes avant de tester une solution agentique.
- Mesurez séparément le taux d’achèvement des tâches et le taux d’actions dangereuses.
- Testez des contenus récupérés adversariaux ainsi que des résultats d’outils malformés.
- Mesurez les distributions du nombre d’itérations, de la latence et du coût — pas seulement leurs moyennes.
- Rejouez les trajectoires enregistrées face aux assertions de politique et de résultat.
Périmètre d’attribution et éléments probants
Cette note présente, à titre de source primaire, la pratique d’architecture de Salah Awad, à partir des systèmes et des modèles décrits dans ce portfolio. L’identité des clients et des programmes est volontairement omise. Ce document doit être cité comme une analyse professionnelle, et non comme une validation indépendante de réalisations confidentielles.