Coulisses : écrire le logiciel d'une machine livrée sans logiciel

Parmi nos réalisations, il y en a une qui résume bien ce qu'on appelle le « sur mesure » : le logiciel complet d'une machine à effort. Le point de départ était simple et inconfortable. Les vérins, importés, étaient arrivés sans logiciel utilisable. Le matériel était là, la machine aussi, mais rien pour la faire fonctionner proprement. Le montage et le pilotage ont été écrits chez nous. Voici comment on aborde ce genre de situation, plus fréquente qu'on ne le croit, et ce qu'un dirigeant doit savoir avant de se lancer.

Un problème plus courant qu'il n'y paraît

Beaucoup d'entreprises achètent du matériel à l'étranger pour des raisons de prix ou de disponibilité : moteurs, vérins, capteurs, cartes électroniques. Le matériel est souvent bon. Le logiciel fourni, quand il existe, l'est beaucoup moins : interface dans une langue que personne ne lit, fonctions limitées à une démonstration, pilote qui ne tourne que sur un vieux système, ou rien du tout. Le fournisseur considère avoir livré une pièce, pas un produit.

À ce stade, il reste trois options : renvoyer le matériel, chercher un autre fournisseur, ou écrire le logiciel qui manque. La troisième est souvent la plus rapide, à condition de l'aborder avec méthode.

Comment on aborde une machine muette

Comprendre ce que le matériel sait faire

La première étape n'est pas d'écrire du code, c'est de lire : documentation constructeur quand elle existe, caractéristiques électriques, protocole de communication. On établit ce que chaque composant accepte comme ordre et ce qu'il renvoie comme information. Quand la documentation manque, on mesure et on teste, prudemment, sur banc.

Définir ce que la machine doit faire, avec ceux qui s'en servent

Une machine à effort n'est pas un vérin qui monte et qui descend. C'est un usage : des réglages, des séquences, des mesures à enregistrer, un affichage lisible pour la personne qui l'utilise. On écrit ces besoins avec l'utilisateur final avant de développer, exactement comme pour un logiciel de gestion.

Mettre la sécurité au centre

Dès qu'un logiciel commande une force physique, la question n'est plus seulement « est-ce que ça marche ? » mais « que se passe-t-il quand ça ne marche pas ? ». Arrêt d'urgence, limites de course et d'effort, comportement en cas de perte de communication ou de coupure de courant : ces cas se traitent en premier, pas à la fin. Sur ce type de projet, une bonne partie du travail consiste à prévoir ce qui ne doit jamais arriver.

Écrire le pilotage, puis l'interface

Une fois les échanges avec le matériel maîtrisés et les sécurités en place, on construit la logique de pilotage, puis l'interface de la machine. L'ordre compte : une belle interface posée sur un pilotage fragile ne sert à rien.

Le prototype avant le prix

Sur un projet matériel, il est impossible d'estimer sérieusement le travail sans avoir touché la machine. C'est pourquoi nos projets sur mesure commencent par un prototype : un premier montage qui prouve que l'on sait commander le matériel et qui fait apparaître les vraies difficultés. C'est seulement ensuite qu'on fixe le prix de la suite. Pour le client, c'est la garantie de ne pas payer un devis gonflé « par précaution », et pour nous, celle de ne pas promettre ce qu'on ne sait pas encore faire.

Ensuite, la méthode est la même que pour nos logiciels : des versions testables régulièrement, des essais avec les utilisateurs, une livraison avec formation, et le code source remis au client avec sa documentation. Une machine dont le logiciel appartient au fabricant d'un vérin est une machine qui dépend d'un tiers. Une machine dont vous avez le code est une machine que vous pouvez faire évoluer.

Les questions à vous poser avant de lancer un projet de ce type

• Le matériel est-il documenté ? Même partiellement, une documentation fait gagner un temps considérable. Demandez-la au fournisseur avant l'achat, pas après.
• Qui utilisera la machine, et comment ? Un opérateur formé, un public, un patient, un sportif ? L'interface et les sécurités en dépendent.
• Quelles mesures faut-il garder ? Une machine qui enregistre ses séances ou ses cycles peut alimenter un suivi, un rapport, un logiciel métier.
• Qui maintiendra le logiciel dans trois ans ? Exigez le code source et la documentation, quel que soit le prestataire.
• Le matériel est-il le bon ? Parfois, le prototype montre qu'un composant ne tiendra pas l'usage prévu. Mieux vaut le savoir avant d'en commander cinquante.

Au-delà de la machine à effort

Ce projet n'est pas un cas isolé dans notre activité. Nous avons aussi conçu un jeu de salon où l'on lance une balle sur un écran pour répondre à un quiz, avec détection de l'impact et classement en direct, ou des échecs en réalité augmentée où le joueur est détouré en temps réel et incrusté sur l'échiquier. Le point commun : du matériel, du logiciel, et quelqu'un qui doit s'en servir sans manuel. Vous pouvez parcourir ces projets sur la page Réalisations.

Vous avez une machine, un appareil ou un matériel qui attend son logiciel ? Racontez-nous ce qu'il doit faire lors d'un rendez-vous de 30 minutes, gratuit, en visio ou au studio à Nevers.