Tests logiciels et machines CNC : quand la qualité du code pilote l'usine

Article sponsorisé

J'ai passé sept ans à tester des applications web. Des formulaires, des APIs, des parcours utilisateur. Quand un test échoue, au pire, un bouton ne fonctionne pas. L'utilisateur rafraîchit la page, et la vie continue.

Et puis j'ai discuté avec un ingénieur qui teste le firmware des machines cnc. Un seul bug dans le code de contrôle moteur, et c'est une fraise de 12 mm lancée à 18 000 tours/minute qui part dans la mauvaise direction. On ne parle plus d'un message d'erreur en rouge dans la console. On parle d'une pièce en aluminium fichue, d'un outil cassé à 200 euros, et potentiellement d'un opérateur en danger.

Ça remet les choses en perspective.

Le logiciel au cœur des machines-outils

Une fraiseuse CNC moderne n'est pas un simple outil mécanique. C'est un système informatique complet : un contrôleur numérique interprète du G-code (le langage de programmation des machines-outils), pilote des servomoteurs via des boucles de rétroaction en temps réel, gère les capteurs de température et de vibration, et coordonne le changement d'outil automatique.

Sur une machine récente, on parle de 500 000 à 2 millions de lignes de code firmware. C'est l'équivalent d'une grosse application SaaS — sauf que le temps de réponse se mesure en microsecondes, pas en millisecondes. Et qu'un plantage ne produit pas un écran blanc, mais un crash mécanique.

Les constructeurs comme frcnctec.com proposent aujourd'hui des gammes qui vont de la petite fraiseuse de bureau aux machines industrielles grand format. Quel que soit le format, le logiciel embarqué est le cerveau de la machine. Et ce cerveau doit être testé avec une rigueur que beaucoup de développeurs web n'imaginent même pas.

La pyramide de tests, version industrielle

On connaît la pyramide classique : tests unitaires à la base, tests d'intégration au milieu, tests E2E au sommet. En QA industriel CNC, cette pyramide existe — mais elle a des étages supplémentaires que notre monde web n'a pas.

Tests unitaires du firmware

Comme chez nous. On isole chaque fonction du contrôleur : le parseur G-code, le calcul de trajectoire, l'interpolation linéaire et circulaire, la compensation d'outil. Les frameworks varient — souvent du C/C++ avec CppUTest ou Unity (pas le moteur de jeu, le framework de test embarqué). La couverture visée est généralement au-dessus de 90 %, ce qui ferait rêver pas mal d'équipes web.

La différence majeure : les contraintes de temps réel. Un test unitaire qui vérifie qu'une fonction de calcul de trajectoire retourne le bon résultat n'est pas suffisant. Il doit aussi vérifier qu'elle le retourne en moins de X microsecondes. Le déterminisme temporel est un critère de qualité au même titre que la justesse du résultat.

Tests d'intégration matériel-logiciel (HIL)

C'est là que ça diverge radicalement de notre monde. Le Hardware-in-the-Loop simule le comportement physique de la machine (moteurs, capteurs, outil) pendant que le vrai firmware tourne sur le vrai contrôleur. On injecte des signaux simulés et on vérifie les réponses.

Ça ressemble conceptuellement à nos tests d'intégration avec une base de données réelle — sauf qu'ici, la « base de données » est un modèle physique qui simule l'inertie d'un moteur, la flexion d'un outil sous charge, ou la résonance d'une broche à 24 000 tours/minute.

Tests de simulation numérique

Avant de lancer un programme d'usinage sur une vraie machine, on le simule intégralement sur un jumeau numérique. Chaque trajectoire, chaque changement d'outil, chaque accélération est calculée virtuellement. Si la simulation détecte une collision entre l'outil et le bridage, ou un dépassement des limites de course, le programme est bloqué.

Ce concept de jumeau numérique est au cœur de la transformation vers l'Industrie 4.0. L'article sur la fraiseuse cnc et ia détaille comment l'intelligence artificielle s'intègre dans cette chaîne : maintenance prédictive, optimisation automatique des paramètres de coupe, détection d'anomalies en temps réel.

Tests fonctionnels sur machine réelle

L'équivalent de nos tests E2E. On charge un programme de référence (souvent une pièce normalisée avec des géométries connues), on usine, et on mesure le résultat avec une machine à mesurer tridimensionnelle (MMT). Tolérance typique : ±0.01 mm. Essayez de tester un alignement CSS à ce niveau de précision.

Ce que le QA industriel m'a appris

En discutant avec des ingénieurs CNC et en creusant le sujet, j'ai identifié plusieurs pratiques qui mériteraient de migrer vers notre monde du développement web.

Le test de régression physique

En CNC, chaque mise à jour firmware est suivie d'un usinage de pièce de référence. Si les cotes dérivent, même de quelques microns, la mise à jour est rejetée. C'est brutal, mais efficace.

Combien d'entre nous testent systématiquement les performances de rendu après un bump de version de framework ? Le concept est le même : une référence mesurable, un écart maximum toléré, un verdict automatique. C'est exactement ce que font les tests de performance que l'on couvre dans notre guide des tests de performance.

Le logging temps réel

Les contrôleurs CNC loggent tout : chaque commande envoyée, chaque position moteur lue, chaque température mesurée, chaque vibration détectée. En cas d'incident, la reconstitution est immédiate. Pas de « on n'a pas les logs, c'est en prod ».

Pour nos applications, l'équivalent serait de l'observabilité systématique — traces distribuées, métriques applicatives, logs structurés. On en parle dans le contexte CI/CD, mais peu d'équipes l'implémentent aussi rigoureusement que le fait l'industrie.

Le mode dégradé explicite

Une machine CNC ne « crashe » pas silencieusement. Quand un capteur retourne une valeur hors limites, la machine passe en mode dégradé : réduction de vitesse, arrêt contrôlé, ou blocage total selon la gravité. Chaque mode est testé, documenté, et l'opérateur sait exactement ce qui se passe.

Combien de nos applications ont un mode dégradé explicite et testé ? « Le service de paiement est down, on affiche un message et on propose de réessayer dans 5 minutes » — c'est un mode dégradé. Mais est-il testé automatiquement ? Dans la plupart des cas, non.

Le TDD fonctionne aussi avec du métal

Ce qui m'a le plus surpris, c'est que les principes fondamentaux du QA restent les mêmes, quel que soit le domaine. La dette technique existe aussi dans le firmware CNC — des raccourcis pris il y a dix ans qui rendent le code difficile à tester aujourd'hui. Le TDD, tel qu'on l'a abordé dans notre introduction au Test-Driven Development, s'applique aussi au code embarqué.

La différence fondamentale, c'est le coût de l'erreur. En web, un bug en production coûte du temps, de la frustration, peut-être du chiffre d'affaires. En CNC, un bug en production coûte du matériel, de la matière première, et potentiellement la sécurité d'un opérateur. Cette asymétrie explique pourquoi l'industrie teste plus rigoureusement que le web — et pourquoi on aurait tout intérêt à s'en inspirer.

La prochaine fois que vous râlez contre l'écriture d'un test unitaire pour un composant React, pensez à l'ingénieur qui doit valider que sa boucle de contrôle moteur ne dévie pas d'un micron. Ça aide à relativiser.