Shippy : anatomie de l'agent IA maritime signé Ai2
Actualités IA

Shippy : anatomie de l’agent IA maritime signé Ai2

· · 3 min de lecture

Comment construire un agent IA fiable quand une mauvaise réponse peut envoyer un navire de patrouille à des kilomètres de sa cible ? L’équipe Skylight d’Ai2 a publié le 15 juillet 2026 le retour d’expérience complet sur Shippy, son agent de surveillance maritime en temps réel. Leur verdict : le vrai chantier, ce n’était pas le modèle, mais le système autour.

Shippy répond à des analystes chargés de protéger l’océan. Selon Ai2, une erreur peut coûter des ressources déjà sous tension et mettre des équipages en danger. D’où une obsession revendiquée : la fiabilité avant tout, vérifiée en continu contre les données live de Skylight, mises à jour à chaque nouveau signal satellite ou signal navire.

Soul, skills et config : les trois briques de l’agent

Ai2 décompose Shippy en trois éléments. Le soul est le system prompt : il fixe la persona et les limites de comportement. Les skills indiquent comment traiter chaque type de requête. Ces deux couches sont figées dans une image Docker, un artefact versionné qui définit ce qu’est Shippy.

La config couvre le reste : le harness d’agent (ici OpenClaw, un framework open-source), le LLM (Shippy s’appuie actuellement sur Claude Opus 4.6) et les réglages runtime. Les secrets comme les clés API sont injectés à l’exécution. Changer de modèle ou de harness devient une modif de config, pas une reconstruction.

Détail intéressant pour les développeurs : les skills de Shippy suivent la même spec agent-skills que des outils de code comme Claude Code et Codex, à savoir de simples fichiers markdown avec un frontmatter structuré. Shippy sait interroger l’API Skylight, retrouver les frontières des zones économiques exclusives (EEZ) et des aires marines protégées (MPA), interpréter les trajectoires de navires et générer des liens de carte interactifs.

Le soul pose aussi des interdits explicites. Shippy ne tranche pas la légalité : « c’est une décision qui revient aux humains, pas à un agent », écrit Ai2. Il ne spécule pas au-delà de ce que les données supportent. Ces bornes sont dans le system prompt, donc auditables et modifiables, pas noyées dans un fine-tuning.

Des outils déterministes pour un agent qui ne l’est pas

« Vous ne pouvez pas contrôler ce que le modèle décide de faire, mais vous pouvez rendre ses outils prévisibles », résume l’équipe. Concrètement, Shippy ne construit plus ses appels API à la main. Dans les premiers prototypes, cette approche produisait un flot de bugs subtils : pagination cassée qui perdait des résultats en silence, erreurs d’encodage de géométrie, requêtes correctes en apparence mais renvoyant de fausses données.

La solution : un CLI Skylight dédié. Shippy lance une commande unique, du type skylight events search avec des filtres typés, et le CLI gère l’authentification, la pagination et la sortie structurée. Cette sortie est toujours écrite dans un fichier JSON local plutôt que passée dans le shell, car les gros jeux de résultats saturaient les buffers ou cassaient des outils comme jq.

Côté hébergement, chaque utilisateur parle à Shippy dans sa propre session éphémère isolée. Ai2 a bâti Mothership, une plateforme qui provisionne un déploiement Kubernetes dédié par session. Le JWT Skylight de l’utilisateur est injecté à la provision, ce qui scope les appels API à ses seules données. C’est un enjeu réel : Skylight sert des centaines d’agences gouvernementales et d’ONG dans plus de 70 pays, chacune avec ses zones d’intérêt et ses watchlists.

Sur quel modèle tourne Shippy ?

Selon Ai2, Shippy s’appuie actuellement sur Claude Opus 4.6. Le modèle est un paramètre de config : le remplacer ne nécessite pas de reconstruire l’agent.

Qu’est-ce qu’OpenClaw ?

OpenClaw est le framework d’agent open-source qui sert de harness à Shippy. C’est lui qui orchestre l’exécution de l’agent, indépendamment du modèle et des skills.

Pourquoi un CLI plutôt que des appels API directs ?

Parce que l’API Skylight a des dizaines de types d’entrées, des filtres imbriqués et des géométries complexes. Le CLI transforme cette complexité en une interface prévisible et auto-documentée, ce qui réduit les erreurs de l’agent.

Mis à jour le 18 juillet 2026. Signaler une erreur.

Tristan Cavel

Développeur full-stack · Spécialiste APIs et agents IA

Tristan bidouille du code depuis le collège et construit des produits dessus depuis 2016. Il est passé par deux startups (une en edtech lyonnaise, une en fintech parisienne), et depuis 2022 il est freelance full-stack depuis Bordeaux, avec une spécialisation LLM et agents IA qui s'est imposée naturellement : c'était soit apprendre à utiliser l'API OpenAI, soit continuer à coder des formulaires de contact. Sa première intégration sérieuse d'un LLM date de janvier 2023, sur un prototype de bot de support pour une scale-up SaaS B2B lyonnaise. Depuis, il a poussé en prod chez huit clients différents : chatbots spécialisés, pipelines RAG avec bases vectorielles, agents autonomes avec n8n et LangChain, et récemment des intégrations Claude Code dans des workflows de dev. Il teste chaque nouvel outil dans son lab perso avant de le recommander à un client, c'est devenu son réflexe. Sur Zoom IA, il écrit les guides techniques qui ne trichent pas : API ChatGPT pour les vrais devs, comparatifs n8n vs Make avec le retour d'expérience honnête, installation d'agents autonomes, LangChain vs LangGraph sous l'angle ce qui pète en prod. Il signe aussi les benchmarks de modèles avec du code testé, pas des scores recopiés des papers. Son parti-pris éditorial : montrer le code, citer les versions exactes, donner les commandes qui marchent, et ne pas cacher ce qui est cassé dans les outils. Il maintient un repo GitHub perso avec les scripts qu'il partage.

Ne rate rien de l'actu IA

Le Brief IA, chaque semaine dans ta boite. Gratuit, concret, sans spam.