J’ai eu cette conversation plus de fois que je ne peux en compter. Un ingénieur ou un fondateur tient une carte, un module, un build firmware et demande : « Est-ce production-grade ? » Il cherche une validation. Ce qu’il obtient généralement de ma part, c’est une question en retour : suffisamment bon pour quoi, exactement ?

Cette question n’est pas une esquive. C’est toute la réponse.

« Production-grade » semble devoir désigner une barre fixe, une ligne entre l’amateur et le professionnel, entre le prototype et le produit. En pratique, ce n’est pas le cas. La barre bouge selon ce qu’on construit, qui l’utilise, dans quelles conditions, et ce qui se passe quand quelque chose tombe en panne. Un design parfaitement adapté à un appareil de bien-être grand public serait totalement inacceptable pour un dispositif médical de classe II. Le même PCB, la même puce, la même architecture firmware. Des barres différentes.

Cela semble évident une fois dit à voix haute. Pourtant, je vois cette confusion se manifester dans de vrais projets, en général dans l’une de ces deux directions.

La première : confondre la classe des composants avec la qualité de l’ingénierie. L’idée que l’utilisation de composants à usage industriel, d’un boîtier en métal et de connecteurs renforcés rend quelque chose production-grade. Ce n’est pas exactement faux, mais c’est dans le mauvais sens. Un appareil construit avec des composants génériques, doté d’une couverture de test solide, d’états d’erreur bien définis et d’une architecture firmware qui gère les pannes correctement, est plus « production-grade » dans tout sens utile qu’un appareil construit avec des pièces coûteuses et sans vrai plan de test. Le choix des composants compte, mais il est en aval de la compréhension de ce dont le produit a réellement besoin pour tenir dans le temps.

La seconde confusion : traiter « production-grade » comme quelque chose qu’on atteint une fois, plutôt que comme une barre qu’on définit en amont. Les équipes franchissent une étape, un premier prototype fonctionnel, une démonstration réussie, des premières unités sur le terrain, et commencent à utiliser le terme comme si le fait de le prononcer clôturait quelque chose. Ce n’est pas le cas. Le terme décrit une cible : ce design, dans ce cas d’usage, répond aux exigences que nous avons définies pour lui. Si ces exigences n’ont jamais été écrites, la phrase n’est que du bruit.

Les exigences sont la partie difficile, et elles sont bien plus spécifiques que la plupart des gens ne l’imaginent.

Pour un produit IoT grand public, on parle de certification FCC et ISED, CE pour l’Europe, d’une spec de fiabilité claire pour l’environnement opérationnel, et d’une architecture firmware qui gère les mises à jour OTA, la récupération après crash et la mise hors tension sans corrompre l’état. C’est un vrai travail, pas anodin. Mais c’est délimité.

Pour un dispositif médical, même un objet connecté de bien-être situé dans le bas du spectre réglementaire, le périmètre s’élargit de façon significative. Le logiciel doit suivre la norme IEC 62304, on constitue un dossier d’historique de conception, et chaque décision de conception doit être traçable jusqu’à une exigence. Le même build firmware qui passerait sans problème dans un contexte grand public nécessite un processus formel de gestion des risques en dessous.

Pour un système de contrôle industriel, ou tout ce qui s’inscrit dans une application automobile, les normes bougent encore. ISO 26262 pour l’automobile. IEC 61508 pour la sécurité fonctionnelle dans le domaine industriel. Ni l’une ni l’autre ne s’ajoute après coup : elles façonnent l’architecture dès le début.

L’écart de coût entre ces niveaux est réel. Un dépôt FCC/CE pour un produit grand public coûte généralement entre 10 000 et 30 000 dollars selon ce que contient l’appareil et la clarté de la première soumission. Ajouter la conformité IEC 62304 à un projet firmware peut doubler les heures d’ingénierie. Suringéniérer par rapport au mauvais standard coûte de l’argent. Sous-ingéniérer par rapport au bon standard crée de la responsabilité.

Ce n’est pas une raison d’éviter la question. C’est une raison d’y répondre correctement depuis le début.

Ce que je constate dans la pratique : les projets qui se passent bien sont ceux où quelqu’un s’assoit tôt, avant le premier schéma, avant la première ligne de firmware, et rédige une courte réponse à quelques questions concrètes. Quels modes de défaillance sont inacceptables ? Quel est l’environnement opérationnel ? Dans quelle catégorie réglementaire ce produit s’inscrit-il ? Que signifie « fiabilité », en chiffres ? Un appareil avec une durée de vie de dix ans sur le terrain en extérieur a des exigences différentes d’un appareil posé sur un bureau et remplacé tous les deux ans. Mettre cela par écrit change ce qu’on construit.

Les projets qui peinent sont ceux où « production-grade » sert de raccourci pour « on veut que ça ait l’air professionnel », sans que personne ne traduise ce ressenti en exigences spécifiques. Ces projets produisent généralement quelque chose de coûteux, en retard, et qui n’atteint pas tout à fait la barre, parce que la barre n’a jamais vraiment été tracée.

Il y a aussi une version de cette confusion qui apparaît du côté des composants. J’ai vu des clients dépenser bien plus qu’il ne le fallait pour des classes de composants que le cas d’usage ne justifiait pas : plage de température industrielle pour un produit qui ne quittera jamais un bureau climatisé, finition ENIG sur des cartes où l’HASL aurait été suffisant. Cet argent aurait été plus utile investi dans de vrais tests, une analyse des modes de défaillance ou la préparation à la certification. Signaler la qualité par les composants est une chose réelle, mais cela ne se substitue pas au travail d’ingénierie qui crée une fiabilité réelle.

La définition honnête de « production-grade » : un design dont les critères d’acceptation sont précis, dont les tests couvrent les modes de défaillance qui comptent vraiment pour ce cas d’usage, dont les exigences réglementaires pour cette catégorie de produit sont satisfaites, et dont quelqu’un peut expliquer par écrit pourquoi chacune de ces barres a été placée là où elle l’est. Voilà tout. Cela s’applique à un capteur IoT à 50 $ comme à un instrument médical à 5 000 $. La barre est différente. Le processus de la définir, clairement et en amont, est le même.