MCP et fiches techniques : donner à un assistant IA le contexte de votre projet embarqué
Le problème n'est pas que le modèle ignore votre matériel. C'est qu'il ne sait pas qu'il l'ignore, et produit une réponse assurée à partir de ce qu'il a vu ailleurs. Toute la question du contexte se résume à remplacer cette mémoire approximative par une lecture, contrôlée et traçable.
Ce que MCP change
Le Model Context Protocol est un protocole ouvert qui standardise la façon dont un assistant accède à des ressources externes. Trois primitives suffisent à comprendre son intérêt en embarqué.
Les ressources sont des données que le modèle peut lire : un manuel de référence indexé, l'arbre des sources du projet, un fichier de définition de registres SVD.
Les outils sont des actions qu'il peut déclencher : compiler, lancer une analyse statique, interroger un traceur, lire un registre sur la cible via une sonde.
Les invites sont des gabarits réutilisables : « analyse ce pilote selon nos règles maison ».
L'effet pratique est direct. Un assistant qui peut lire le SVD de votre microcontrôleur ne peut plus inventer un registre : il n'a plus besoin de deviner. Un assistant qui peut compiler voit ses propres erreurs et les corrige avant de vous répondre.
Rendre une fiche technique exploitable
Un manuel de référence de microcontrôleur fait couramment 2 000 à 3 500 pages. Le donner entier dans le contexte est impossible et, quand la fenêtre le permet techniquement, contre-productif : la précision se dégrade quand le contexte est saturé de pages sans rapport.
Les approches qui fonctionnent, par ordre d'efficacité.
Le fichier SVD ou l'en-tête du composant. C'est la description structurée et exacte des registres, des champs de bits et de leurs valeurs de reset. Quelques centaines de kilooctets de données non ambiguës, infiniment plus utiles que le PDF correspondant.
L'extraction ciblée de sections. Fournir le chapitre du périphérique concerné plutôt que le manuel. Un index par périphérique, construit une fois, permet de servir la bonne section à la demande.
L'indexation vectorielle du manuel. Utile pour les questions ouvertes, mais à surveiller : les tableaux de registres se découpent mal en fragments, et une réponse tirée d'un fragment tronqué est pire qu'une absence de réponse. Vérifiez toujours ce type de réponse contre la source.
Le point à retenir : une donnée structurée bat un document, toujours. Cherchez d'abord le SVD, le fichier de description de carte, l'en-tête généré, avant de penser au PDF.
Concevoir un agent qui serve à quelque chose
Un agent est un assistant à qui l'on confie une boucle : agir, observer le résultat, corriger. En embarqué, cette boucle n'a de valeur que si l'observation est réelle.
Une boucle utile ressemble à ceci : écrire le code, compiler, lire les erreurs, corriger, relancer l'analyse statique, exécuter le banc de test sur simulateur ou sur cible, lire la trace.
Deux garde-fous sont indispensables. Une borne d'itérations, sinon un agent tourne indéfiniment sur une erreur qu'il ne sait pas résoudre, en consommant du temps et des jetons. Et une séparation stricte entre lecture et écriture : un agent peut compiler, analyser, lire des registres, mais ne devrait jamais flasher une carte ni pousser sur une branche partagée sans validation humaine.
L'erreur classique consiste à donner à l'agent des outils qui échouent en silence. Un outil de compilation qui renvoie un code de sortie nul en cas d'erreur transforme la boucle en générateur de code faux et confiant.
Configurations réutilisables
Retaper les contraintes du projet à chaque conversation est la principale perte de temps observée. Les contraintes stables méritent d'être écrites une fois, dans un fichier versionné du dépôt : règles de codage, taille de pile, interdiction d'allocation dynamique, conventions de nommage, périphériques utilisés.
Deux propriétés en découlent. Elles s'appliquent à toute l'équipe, donc le résultat est homogène. Et elles évoluent en revue de code comme le reste : quand une règle change, elle change pour tout le monde et l'historique le montre.
La propriété intellectuelle, à traiter avant le premier essai
C'est la question qui bloque le plus souvent le déploiement en entreprise, et elle se règle par des décisions explicites plutôt que par une interdiction générale.
Où partent les données. Un service hébergé reçoit tout ce que vous mettez dans le contexte, y compris le code sous accord de confidentialité et les extraits de manuels sous licence. Un modèle exécuté sur votre infrastructure ne pose pas ce problème, au prix d'une qualité moindre sur les tâches complexes.
Ce que dit le contrat. Les offres professionnelles excluent en général l'entraînement sur vos données, contrairement aux offres grand public. C'est une clause à vérifier, pas à supposer.
Le statut du code produit. Un code généré n'est pas nécessairement protégeable par le droit d'auteur dans toutes les juridictions, ce qui compte si votre valeur réside dans le firmware.
La contamination par licence. Un modèle peut reproduire des fragments proches de code sous GPL vu à l'entraînement. Sur un firmware propriétaire, cela justifie une analyse de composition logicielle sur le code généré, au même titre que sur les dépendances tierces.
La règle pratique : classez ce qui peut sortir et ce qui ne le peut pas, avant d'ouvrir l'outil. Un fichier de configuration au niveau du dépôt peut d'ailleurs interdire l'envoi de certains répertoires.
Ce que ça donne concrètement
| Sans contexte | Avec contexte structuré |
|---|---|
| Registres plausibles mais inexistants | Registres lus dans le SVD |
| Style incohérent d'un fichier à l'autre | Conventions du projet appliquées |
| Erreurs découvertes à la compilation manuelle | Corrigées dans la boucle de l'agent |
| Contraintes retapées à chaque session | Écrites une fois, versionnées |
| Code confidentiel envoyé sans arbitrage | Périmètre décidé et appliqué |
Références
- Model Context Protocol, spécification, ressources, outils et invites
- CMSIS, System View Description, SVD
- Open-CMSIS-Pack, description structurée des composants et des cartes
- OWASP, Top 10 for LLM Applications, fuites de données et gestion du contexte
Pour aller plus loin
Mettre cela en place demande de choisir les outils, d'écrire les serveurs de contexte adaptés à votre matériel et de définir la boucle de validation. C'est précisément le contenu de notre formation au développement embarqué assisté par IA, qui couvre les assistants en IDE et en ligne de commande, l'ingestion des manuels, MCP, la conception d'agents et la validation du code produit.