Un collègue m'a dit récemment qu'il n'avait plus besoin d'outils comme UMTSM parce qu'il utilisait l'IA pour générer son code. Je l'ai entendu plus d'une fois. C'est un défi légitime qui mérite une réponse honnête — pas une réponse défensive.
Je vais essayer d'en donner une.
Ce que l'IA sait vraiment faire
Je ne vais pas prétendre le contraire. Si vous demandez à Claude ou GPT-4 d'implémenter une machine à états simple en C++, vous obtiendrez quelque chose de raisonnable en quelques secondes. Pas d'installation, pas de courbe d'apprentissage, pas de coût de licence. Pour un contrôleur de feux de circulation à 5 états ou un prototype rapide, ça fonctionne.
Le développeur décrit le comportement en langage naturel, le modèle produit le code, le développeur l'ajuste. Rapide, flexible, sans friction.
Pour les systèmes petits, autonomes et non critiques, c'est genuinement suffisant. Le nier serait malhonnête.
Là où la comparaison s'effondre
Dès que le système dépasse le stade du prototype, le tableau change.
La correction n'est pas garantie
Le code de machine à états généré par IA a l'air correct. Il l'est souvent. Mais "souvent" n'est pas la même chose qu'"toujours" — et dans les systèmes embarqués, notamment en défense, automobile et contrôle industriel, "souvent correct" n'est pas une spécification acceptable.
UMTSM génère du code à partir d'un modèle formel. Le même fichier .umt, exécuté par le même générateur, produit une sortie identique octet pour octet à chaque fois. Le comportement est défini par la sémantique du DSL, pas par le niveau de confiance du modèle ce jour-là. Il n'y a pas d'hallucination dans un générateur de code déterministe.
La maintenance : là où l'IA échoue silencieusement
Demandez à l'IA de générer une machine à états aujourd'hui. Revenez dans six mois quand une exigence change. Demandez-lui maintenant de mettre à jour le code.
Le modèle ne se souvient pas de la conversation précédente. Il ne sait pas quelles décisions de conception étaient intentionnelles et lesquelles étaient accidentelles. Il va générer quelque chose de nouveau. Vous devrez comparer deux sorties IA et décider quoi conserver. Ce n'est pas du génie logiciel — c'est de l'archéologie.
Avec UMTSM, la conception vit dans le fichier .umt. Changez le modèle, régénérez le code. Le diff est déterministe et significatif. Ce qui a changé dans le modèle est exactement ce qui a changé dans la sortie. Le contrôle de version, la revue de code et la traçabilité fonctionnent comme prévu.
Workflow IA après un changement d'exigence :
Décrire le changement en langage naturel
→ L'IA génère un nouveau code
→ Comparer avec la sortie IA précédente
→ Réconcilier manuellement les différences intentionnelles vs accidentelles
→ Tout re-tester
→ Espérer que rien de subtil n'a été cassé
Workflow UMTSM après un changement d'exigence :
Modifier le fichier .umt
→ Lancer le générateur
→ Le diff est propre et sémantiquement significatif
→ Re-tester les chemins affectés
Les équipes ne passent pas à l'échelle avec du code généré par IA
Un développeur utilisant l'IA peut être productif. Cinq développeurs invitant indépendamment l'IA à générer des machines à états connexes produiront cinq styles de codage différents, cinq hypothèses différentes sur la concurrence, cinq stratégies différentes de gestion des erreurs.
UMTSM impose une structure uniforme sur toute la base de code. Chaque machine à états a le même squelette généré, la même API de cycle de vie, le même modèle de threads. Un développeur rejoignant le projet le premier jour peut lire n'importe quelle machine à états du système et en comprendre immédiatement la structure, parce que la structure est toujours la même.
La certification n'accepte pas "l'IA l'a écrit"
Pour les systèmes développés sous IEC 61508, ISO 26262, DO-178C ou normes de sécurité équivalentes, la chaîne d'outils de développement doit être qualifiée. Chaque transformation de l'exigence au code doit être traçable et auditable.
"Nous avons utilisé un assistant IA" n'est pas un outil qualifié. Il ne peut pas produire un rapport de qualification d'outil. Il ne peut pas démontrer qu'une entrée donnée produit toujours une sortie donnée. Il ne peut pas être soumis comme preuve dans un dossier de sécurité.
UMTSM est conçu dès le départ en tenant compte de la qualification. Le générateur est déterministe. La sémantique du DSL est formellement définie. La transformation du modèle au code est auditable. Ce n'est pas une fonctionnalité que l'IA peut répliquer — c'est une catégorie d'outil fondamentalement différente.
La vraie comparaison
| Critère | Génération de code IA | UMTSM |
|---|---|---|
| Vitesse initiale | Très rapide | Rapide après courbe d'apprentissage |
| Garantie de correction | Aucune | Déterministe par construction |
| Reproductibilité | Non garantie | Identique octet pour octet |
| Maintenance après 6 mois | Difficile | Modifier le modèle, régénérer |
| Cohérence d'équipe | Aucune imposée | Uniforme par conception |
| Traçabilité | Aucune | Modèle → code, complète |
| Aptitude à la certification | Non applicable | Conçu pour ça |
| Régions orthogonales parallèles | Mal gérées | Fonctionnalité de première classe |
| États historiques | Rarement corrects | Profond, superficiel, persistant |
| Scaffolding de tests | Manuel | Généré automatiquement |
| Fonctionne hors ligne / air-gapped | Oui | Oui |
| Coût | Abonnement | Licence d'outil |
Ils ne sont pas vraiment en concurrence
Voilà ce qui m'a surpris quand j'y ai bien réfléchi.
L'IA et UMTSM n'ont pas à être des adversaires. Le développeur doit toujours réfléchir au comportement du système. Il doit toujours décider quels états existent, quels événements déclenchent les transitions, quelles sont les conditions de garde, quelles actions exécuter à l'entrée.
L'IA peut aider dans cette réflexion. Elle peut aider un développeur à rédiger un modèle .umt, suggérer des transitions manquantes, identifier des états inaccessibles, ou expliquer pourquoi une conception particulière ne gère pas correctement un scénario spécifique.
Sans UMTSM :
Développeur → IA → code C++ (non structuré, sans garanties)
Avec UMTSM :
Développeur → (l'IA assiste) → modèle .umt → UMTSM → code C++ garanti
L'IA devient un assistant pour la tâche de modélisation. UMTSM gère la transformation du modèle au code. Le résultat est plus rapide que de le faire seul, et plus sûr que de laisser l'IA produire directement le code final.
Une note sur les développeurs juniors
Une objection que j'entends est qu'UMTSM a une courbe d'apprentissage. C'est vrai. Mais considérez l'alternative.
Un développeur junior utilisant l'IA pour générer une machine à états pour un système embarqué concurrent produira du code qui semble fonctionner. Il passera les tests de base. Il échouera sur le terrain sous une condition de course qui ne survient que toutes les quelques milliers d'heures de fonctionnement.
Un développeur junior utilisant UMTSM écrira un fichier .umt décrivant le comportement, lancera le générateur et recevra automatiquement une infrastructure concurrente correcte. La courbe d'apprentissage concerne la compréhension des concepts de machines à états — c'est la compétence réelle qui doit être développée — pas la gestion correcte des mutex et des threads à la main.
UMTSM ne supprime pas le besoin de penser. Il supprime le besoin de ré-implémenter correctement le même code répétitif à chaque fois.
Conclusion
La génération de code par IA est un outil genuinement utile. Je l'utilise. La plupart des ingénieurs le font. Mais "utile pour le prototypage et l'exploration" n'est pas la même chose qu'"adapté au développement de logiciels embarqués en production à grande échelle."
Le collègue qui m'a dit qu'il n'avait plus besoin d'outils comme UMTSM a probablement raison — pour ce qu'il construit aujourd'hui. Si ses systèmes restent petits et ne nécessitent jamais de certification, l'IA peut être suffisante indéfiniment.
Mais pour les équipes qui construisent des systèmes embarqués complexes, concurrents et critiques pour la sécurité qui doivent être maintenus pendant des années et certifiés selon des normes internationales, la comparaison n'est pas proche. Le déterminisme, la traçabilité, la cohérence d'équipe et la qualification ne sont pas des fonctionnalités optionnelles. Ce sont le travail.
UMTSM a été construit précisément parce que ces contraintes sont réelles, et parce que les outils existants qui les prennent au sérieux sont soit hors de prix, soit mal conçus, soit les deux.
*Fehmi Demiralp est le créateur d'UMTSM, un DSL de machine à états et un framework de génération de code pour le développement C++ embarqué.*
