Claude Sonnet Aide les Cadres Dirigeants à Construire un Directeur IA pour Décisions Critiques en 8 Heures

En une seule journée de travail, une équipe de PDG, CTO, CIO et d'ingénieur IA a assemblé non un chatbot, mais un assistant IA de gestion capable de contester le leadership et de tenir bon sous la pression. À l'intensif fermé Snow BASE, le projet CAITO, Chief AI & Technology Officer, devait prendre des décisions dans un cas de crise de la division de détail et ne changer d'avis que lorsque les faits changent. Le hackathon à Sotchi a été organisé par AI Talent Hub de l'Université ITMO et South HUB.

Les participants avaient huit heures pour résoudre le cas : une grande entreprise de vente au détail fait face simultanément à l'effondrement de son système de recommandation en raison de la dérive de données saisonnière, l'infrastructure fonctionne déjà à sa limite, les dépenses de cloud augmentent plus vite que les revenus, et les nouvelles exigences en vertu de la Loi Fédérale 152-FZ augmentent le risque d'amendes. Sur la table devant le conseil d'administration pèse un choix désagréable : augmenter la capacité du système, geler le développement ou reporter le lancement, avec seulement 14 jours pour décider. L'équipe CAITO a construit un modèle de gestion autour de cette tâche dans lequel l'IA ne devrait pas simplement répondre aux questions, mais maintenir l'équilibre entre les intérêts du PDG, du CFO, du COO et du bloc technique.

C'est précisément là que les LLM ordinaires échouent souvent. Si le modèle continue simplement le dialogue, il commence à s'adapter au dernier et au plus insistant interlocuteur : le PDG fait pression pour la croissance à tout prix, le CFO exige un ROI immédiat et réduit les investissements, le COO rappelle les SLA et les contraintes opérationnelles. En résultat, au lieu d'une position de gestion, vous obtenez un miroir de la pression actuelle.

L'équipe a donc choisi une approche maximalement pragmatique : d'abord construire un raisonnement single-shot robuste, où chaque mouvement nécessite un appel de modèle, puis seulement vérifier si une boucle agentive plus complexe est nécessaire. Ce mode a fourni une latence de réponse prévisible au niveau de quelques secondes, une sortie JSON structurée, et un débogage plus simple dans les conditions du hackathon. Claude Sonnet a été choisi comme le modèle, et le service lui-même a été construit sur Bun et TypeScript avec accès aux Foundation Models de Cloud.

ru via une API compatible avec OpenAI. L'architecture CAITO reposait sur trois piliers. Le premier était un prompt système avec un mandat strict : l'assistant doit d'abord formuler une solution, puis des arguments, enregistrer séparément les conflits de métriques et ne pas changer de position sans nouvelles données.

Le deuxième était workflow.yaml, où les rôles internes, leurs poids et l'ordre des consultations étaient spécifiés : d'abord les faits du ML et de l'économie, puis les contraintes opérationnelles, et seulement ensuite la politique de gestion. Le troisième était la mémoire à long terme.

Y étaient stockés séparément les faits immuables du cas et un historique vivant des décisions prises, des hypothèses, des KPI et des changements de position. Cela a permis au système de se souvenir du contexte et d'expliquer pourquoi l'opinion est restée la même ou a changé. Lors de la présentation, l'équipe a montré trois scénarios.

Dans le premier, CAITO a été confronté à des données contradictoires et l'on a vérifié sur quelles sources il s'appuyait ; pour réduire le risque d'hallucinations, la réponse a commencé à montrer d'où provenaient les chiffres clés. Dans le deuxième scénario, l'assistant a été poussé par le PDG exigeant une action immédiate, mais le système a maintenu son cadre et a répondu que sans nouvelles données, seuls les risques pouvaient être clarifiés, pas la solution réécrite. Dans le troisième scénario, la pression est venue par vagues : d'abord de nouvelles données, puis une attaque émotionnelle, puis un autre lot d'informations.

Ici, CAITO devait distinguer les changements réels de situation de la pression répétée et reconsidérer sa position uniquement sur la base des faits. En parallèle, l'équipe a réussi à assembler une alternative — un pipeline multi-agents de dix rôles spécialisés avec routage de tâches séparé. Sur des métriques individuelles, ce schéma a montré une meilleure analyse, en particulier où il était nécessaire de distinguer avec soin les nouveaux signaux de la vieille pression.

Mais en huit heures, l'avantage principal s'est avéré être non pas la richesse de l'architecture, mais sa fiabilité. À la présentation finale, le gagnant a été choisi par tableau de classement, où 70 pour cent de la note provenait de l'automatisation et 30 pour cent du jury ; la qualité des décisions de gestion et la résistance au stress ont été évaluées, ainsi que la fonctionnalité, la sécurité, la stabilité, l'UX et le coût. La solution single-shot principale a apporté la première place à l'équipe.

De ce cas ressort une conclusion assez pratique. Pour une IA qui doit participer aux décisions de gestion, ce qui importe plus n'est pas le nombre d'agents, mais un mandat clair, des règles d'escalade transparentes et la mémoire des hypothèses précédemment faites. Un orchestre multi-agents impressionnant peut fournir de la profondeur, mais dans le contexte d'une échéance, il perd souvent face à un schéma simple, explicable et robuste.

L'étape suivante pour CAITO est un flux de travail agentic avec function calling, appels de rôles asynchrones, RAG dynamique et traçage complet. Mais dès maintenant, le projet démontre quelque chose de plus important : l'IA peut assumer une partie significative de la préparation de la position de gestion, tandis que la responsabilité finale et la vérification des facteurs non évidents restent avec les humains.