Comment construire un agent IA digne de confiance

Pourquoi l'architecture d'abord

Un faux positif dans une décision maritime coûte des ressources, du temps, voire des vies. Shippy n'a pas eu le luxe de dire « mon modèle hallucine parfois, tu te débrouilles ». Ai2 a construit un système—pas un modèle.

L'anatomie : âme, compétences, config

L'âme, c'est le system prompt. Il définit qui tu es (Shippy) et surtout ce que tu ne fais pas : pas de verdicts légaux, pas de spéculation au-delà des données. Auditable. Modifiable sans retraining.

Les compétences, ce sont des fichiers markdown versionnés qui décrivent comment répondre à une classe de requête :

• ▸Requêter l'API Skylight pour les événements (pêche, transshipment)
• ▸Chercher les zones économiques exclusives et aires marines protégées
• ▸Interpréter les trajectoires de navires
• ▸Générer des liens de cartes interactifs

Une seule question (« montre-moi la pêche en zones côtières du Panama le mois dernier ») enchaîne plusieurs compétences en un seul tour.

La config, c'est tout ce qui change sans toucher au Docker : le modèle (Claude Opus 4.6 aujourd'hui), le harness (OpenClaw, open source), les clés API injectées au runtime.

Résultat : swapper le modèle, c'est une ligne de config. Rebuild zéro.

Outils déterministes pour un agent indéterministe

Tu ne contrôles pas ce que l'agent décide de faire. Mais tu peux rendre ses outils prévisibles.

Ai2 a construit une CLI Skylight typée entre Shippy et l'API. Au lieu de laisser l'agent construire les requêtes API brutes (pagination malformée, erreurs de géométrie, filtres mal interprétés), la CLI standardise : une commande skylight events search --filters typed-flags, la CLI gère l'auth, la pagination, la sortie structurée en JSON sur disque (pas en pipe, sinon débordement de tampon).

Couches empilées :

1. ▸API typée (schémas avec descriptions de champs)
2. ▸CLI déterministe (frontière claire entre l'agent et les détails)
3. ▸Compétences qui référencent les commandes CLI

Chaque couche réduit ce que la suivante peut casser.

Isolation : sandboxes Kubernetes par session

350 gouvernances et ONG dans 70+ pays utilisent Skylight. Un officier des pêches aux Philippines a ses zones à surveiller, ses listes de navires, ses alertes. Zéro fuite vers un autre utilisateur.

Ai2 a bâti Mothership, une plateforme d'hébergement qui lance un déploiement Kubernetes dédié par session utilisateur. À l'ouverture du chat :

• ▸Pods lancés (runtime agent + compétences + CLI Skylight)
• ▸JWT utilisateur injecté → requêtes API limitées à ses données
• ▸Fichiers générés pendant l'analyse existent uniquement dans la session

Réseau restreint au minimum nécessaire.

Évaluer l'agent, pas le modèle

Les benchmarks classiques testent des questions statiques sur un modèle seul. Inutile pour un agent en production.

Ai2 a bâti son propre système d'évaluation qui note l'agent complet : modèle + compétences + sandbox + récupération de vraies données Skylight (mises à jour en direct). Comment choisit-il les outils ? Interroge-t-il les bonnes données ? Sait-il quand s'arrêter ?

Vrais défis, vrais scores.

À emporter

Si ton agent pilote quelque chose d'important (analyse de données sensibles, décisions opérationnelles, argent), copie ce playbook :

• ▸Sépare soul/skills/config
• ▸Standardise l'interface entre ton agent et tes données (CLI typée > API brute)
• ▸Iso les utilisateurs proprement
• ▸Évalue sur des cas réels, pas des benchmarks

La fiabilité, c'est la fonctionnalité qui écrase toutes les autres.