L’automatisation de la nutrition sportive est le Graal de beaucoup d’athlètes amateurs. On veut la précision d’un nutritionniste sans la charge mentale.
Mon objectif était simple : synchroniser mes entraînements (Intervals.icu / nolio.io) avec mes besoins nutritionnels (Hexis.live) et générer des plans de repas automatiques.
Pour ceux qui ne connaissent pas, Hexis est une plateforme de nutrition intelligente qui calcule en temps réel vos besoins énergétiques (glucides, protéines, lipides) selon l’intensité de vos séances de sport passées et futures. Le problème ? Hexis n’a pas d’API publique pour la création de repas.
Voici comment j’ai combiné Reverse Engineering, Man-in-the-Middle, Design Agentique Avancé, Meta-MCP et n8n pour construire un système autonome et économique.
1. Le Hack : Reverse Engineering & Man-in-the-Middle
Puisque la porte d’entrée était fermée, je suis passé par la fenêtre. Pour automatiser l’enregistrement des repas, j’ai mis en place une attaque Man-in-the-Middle (MITM) pour écouter le trafic entre l’application mobile et les serveurs.
Contre toute attente, cette interception s’est révélée plus simple à mettre en place sur iPhone que sur Android, me permettant de cartographier rapidement la structure des APIs privées.
J’ai découvert que l’API ne se contente pas d’un ID d’aliment. Elle exige un refCode spécifique (une chaîne Base64 cachée dans les résultats de recherche) pour valider l’enregistrement. Sans ce sésame, l’API renvoie une erreur muette.
J’ai donc encapsulé toute cette complexité (recherche + extraction du refCode + formatage) dans un serveur MCP personnalisé. Pour mes agents IA, l’opération devient transparente : ils demandent “ajoute une banane”, et le serveur gère la cryptographie en coulisse.
2. Architecture du Crew : 2 Pipelines et 10 Agents
Une fois l’accès aux données résolu, j’ai construit le “cerveau” du système avec CrewAI. L’architecture est divisée en deux pipelines distincts pour garantir précision et fiabilité.
🧠 Pipeline 1 : Analyse des Données
Ce premier groupe définit la stratégie nutritionnelle :
- HEXIS_DATA_SUPERVISOR : Le stratège. Il planifie quelles données récupérer (charge d’entraînement, état de récupération). C’est un modèle “Thinking” pur, sans accès aux outils.
- HEXIS_ANALYSIS_REVIEWER : Le nutritionniste. Il analyse les données brutes pour définir les cibles macro-nutritionnelles précises (ex: “Demain, grosse séance, il faut 400g de glucides”).
Thinking Model
(Stratégie & Planification)]:::supervisor B[HEXIS_DATA_EXECUTOR
GPT-4o/Haiku
(Appels API Hexis)]:::executor C[HEXIS_ANALYSIS_REVIEWER
Analyste
(Synthèse & Objectifs)]:::reviewer A -->|Plan de récupération| B B -->|Données brutes| C C -->|Cibles Macros & Énergie| D((Sortie JSON)):::output end subgraph P2["Pipeline 2 : Génération de Repas"] direction TB E[MEAL_PLANNING_SUPERVISOR
Chef Créatif
(Design Culinaire)]:::supervisor F[INGREDIENT_VALIDATION_EXECUTOR
GPT-4o-mini
(Recherche Base de Données)]:::executor G[MEAL_RECIPE_REVIEWER
Contrôleur Mathématique
(Calculs Macros Précis)]:::reviewer E -->|Plan de Repas Théorique| F F -->|Ingrédients Validés (Passio)| G G -->|Menu Final Ajusté| H((Menu Final)):::output end D -.->|Input: Cibles Nutritionnelles| E
🍳 Pipeline 2 : Génération des Repas
C’est ici que la magie opère pour transformer des chiffres en recettes :
- MEAL_PLANNING_SUPERVISOR (Le Chef) : Il conçoit la structure des 4 repas quotidiens en respectant les codes énergétiques (Low/Medium/High Carb) et assure la variété culinaire.
- INGREDIENT_VALIDATION_EXECUTOR (Le Commis) : C’est le seul agent autorisé à parler à la base de données. Il utilise l’exécution parallèle pour valider rapidement l’existence des ingrédients dans la base Passio/Hexis.
- MEAL_RECIPE_REVIEWER (Le Contrôleur) : Il effectue les calculs mathématiques finaux. Si le Chef a prévu trop de poulet, le Réviseur ajuste la portion au gramme près pour tomber à ±5% des cibles.
Cette structure repose sur un principe clé : Séparation Raisonnement/Action. Les modèles “intelligents” (Superviseurs) ne touchent jamais aux outils pour éviter les hallucinations. Ils délèguent l’exécution technique à des modèles plus simples et rapides (Exécuteurs).
Agents de Support
D’autres agents (Weekly Structure, Nutritional Validation, Integration) assurent la cohérence globale de la semaine et la synchronisation finale vers l’app.
3. Infrastructure MCP : Pourquoi Meta-MCP ?
Gérer une flotte d’agents qui ont besoin d’accès variés (Strava, Intervals.icu, nolio.io, Hexis, Météo…) peut vite devenir un cauchemar de sécurité. Je ne voulais pas que chaque agent ait accès à tous les outils.
J’utilise Meta-MCP, une couche d’abstraction essentielle. Pourquoi ? Principalement pour la sécurité et la modularité.
Elle me permet de regrouper les outils par domaine (Sport, Nutrition, Météo) et de ne distribuer à chaque agent que ce dont il a strictement besoin. Ainsi, mon “Exécuteur Hexis” ne risque pas d’aller supprimer par erreur une séance sur Strava. C’est un principe de moindre privilège appliqué aux agents IA.
(Auth & Filtering)}:::router end subgraph Infrastructure ["Infrastructure MCP Distribuée"] direction TB subgraph S1 ["Server: Nutrition"] T1[Hexis API]:::tool T2[Passio DB]:::tool end subgraph S2 ["Server: Sport"] T3[Strava API]:::tool T4[Intervals.icu]:::tool end subgraph S3 ["Server: Context"] T5[OpenWeather]:::tool end end %% Connexions A1 -->|API Key 'Nutrition'| Router A2 -->|API Key 'Sport'| Router Router -->|✅ Autorisé| S1 Router -->|✅ Autorisé| S2 Router -->|✅ Autorisé| S3 %% Flux Logiques (liens invisibles pour le layout ou explicites pour la sécurité) linkStyle 0 stroke:#2e7d32,stroke-width:2px; linkStyle 1 stroke:#2e7d32,stroke-width:2px; %% Explication visuelle du filtrage Router -.->|❌ Bloqué (Scope)| T3 Router -.->|❌ Bloqué (Scope)| T1 class S1,S2,S3 server
4. Optimisation des Coûts : L’IA à prix malin
Lancer des agents autonomes 24/7 a un coût. Pour éviter une facture astronomique, j’ai mis en place une stratégie agressive :
Reverse Proxies & Modèles Alternatifs
J’utilise des Reverse Proxies compatibles OpenAI (comme CLIProxyAPI) pour accéder à des modèles alternatifs très performants. Mention spéciale à DeepSeek et GLM-4.6 (via z.ai) qui offrent désormais des performances proches d’un Claude 3.5 Sonnet pour une fraction du prix.
L’utilisation de modèles spécialisés “Coder” pour les tâches structurées (JSON) permet aussi de réduire drastiquement les coûts sans perte de qualité.
Rotation Automatique
Mon système gère une cascade de modèles. Si le modèle “Premium” (Claude 3.5 Sonnet) atteint son quota ou rate-limit, le système bascule automatiquement sur un modèle “Eco” (GPT-4o-mini ou GLM-4) pour terminer la tâche. C’est transparent pour l’utilisateur et ça sauve la production.
5. L’Orchestration avec n8n
Avoir des agents intelligents ne suffit pas, il faut les faire vivre dans le temps. C’est là qu’intervient n8n.
J’ai mis en place un workflow (meal-planning-weekly) qui tourne chaque dimanche soir :
- Récupération de la charge d’entraînement : Le workflow interroge Intervals.icu (ou nolio.io) pour connaître mes séances de la semaine à venir.
- Optimisation du planning : Un script JS réorganise mes créneaux (ex: “Si grosse sortie vélo le samedi -> Repas riche en glucides le vendredi soir”).
- Appel Asynchrone vers l’IA : n8n déclenche mon script Python CrewAI via un webhook HTTP.
- Pattern Callback : Comme la génération de repas prend du temps (plusieurs minutes de réflexion pour les agents), n8n ne reste pas bloqué. Il attend un “ping” de retour (callback) une fois que les agents ont fini leur travail.
- Distribution : Le résultat final (liste de courses + menu) est envoyé directement sur Telegram.
Conclusion
Ce projet démontre qu’avec une architecture réfléchie, on peut dépasser les limites des API fermées et créer des systèmes IA véritablement utiles au quotidien.
En combinant la puissance de raisonnement des modèles “Thinking”, la précision d’exécution des serveurs MCP, et l’orchestration robuste de n8n, nous ne sommes plus dans le gadget, mais dans l’assistant personnel réel.
Le code est disponible sur mon GitHub. La prochaine étape ? Automatiser la commande des courses via l’API d’un drive… le prochain défi de reverse engineering !