Un de mes clients me l’a dit sans détour vers la fin d’un projet, presque comme un aveu. Rien n’a vraiment bougé, m’a-t-il confié, tant qu’on n’a pas construit le premier prototype. Tout ce qui précédait ne faisait que nous rendre plus confiants sur des choses qu’on n’avait pas réellement vérifiées. C’était sa lecture sur un produit. Je pense qu’elle se généralise à presque tous les projets hardware que j’ai touchés.

Ça se déroule souvent d’une façon assez semblable. Une équipe a une idée. Elle passe des semaines à l’affiner. Schémas blocs, présélection de composants, une nomenclature dans un tableur, une architecture firmware esquissée, peut-être un beau rendu CAO du boîtier. Tout s’aligne sur le papier. Personne n’a rien soudé. Et le projet n’a pas avancé d’un pouce.

La vérité inconfortable sous ce qu’il m’a dit : tant que vous ne construisez rien, vous ne progressez pas. Vous faites des plans. Ce n’est pas la même chose, et le hardware punit cette confusion bien plus durement que le logiciel.

Pourquoi le papier vous ment

Un schéma qui a l’air correct ne vous dit presque rien sur le fait que le design fonctionne. J’ai validé des schémas dont j’étais sincèrement satisfait, puis regardé la première carte faire quelque chose que le schéma n’avait aucun moyen de prévoir. Un régulateur qui oscille à cause d’un choix de routage que le schéma ne capture pas. Un capteur qui lit parfaitement au banc et qui dérive dès qu’il se retrouve à côté d’un convertisseur à découpage. Un bus I2C qui fonctionne avec deux périphériques et s’effondre avec cinq parce que personne n’a additionné la capacité du bus.

Rien de tout cela n’apparaît en phase de conception. C’est impossible. La phase de conception est un modèle, et le modèle omet précisément les parties de la réalité qui ont tendance à vous mordre : l’inductance parasite, le couplage thermique, les tolérances de connecteurs, le comportement réel d’une pièce par rapport à sa fiche technique, la façon dont le timing de votre firmware entre en collision avec un périphérique que vous supposiez instantané.

C’est la partie que personne ne vous dit quand on répète « mesurer deux fois, couper une fois ». En hardware, certaines choses ne se connaissent qu’en coupant. La mesure dont vous avez besoin n’existe pas tant que la carte n’est pas sur le banc avec une sonde d’oscilloscope dessus.

Le rôle du prototype, c’est d’avoir tort

Voici le renversement qui change la façon de travailler : le premier prototype n’est pas censé réussir. Son rôle, c’est d’avoir tort de manière précise et instructive. Chaque erreur qu’il révèle est une question à laquelle on répond. Vous vouliez que la carte révèle que le routage du convertisseur buck est bruyant, que le placement de l’antenne tue votre portée, que le boîtier retient assez de chaleur pour pousser le MCU en throttling thermique. Mieux vaut l’apprendre à la révision une de la carte que sur les unités pour lesquelles vous avez déjà fait l’outillage.

Un prototype qui fonctionne parfaitement du premier coup n’est pas un triomphe. En général, cela signifie que vous avez construit quelque chose de si conservateur qu’il n’a rien testé que vous ne saviez pas déjà. Les projets qui avancent le plus vite sont ceux où le premier build échoue d’une manière dont l’équipe apprend, et où le deuxième build échoue différemment, à un niveau plus élevé. Ça, c’est du progrès. Deux révisions d’échec éclairé valent mieux que six mois d’un design qui n’a jamais quitté le tableur.

Je veux être prudent ici, parce que le « fail fast » se fait détourner en excuse pour bâcler. L’idée n’est pas de construire n’importe comment. L’idée est de construire la plus petite chose qui met votre hypothèse la plus risquée face à la réalité physique, aussi tôt que vous pouvez vous le permettre.

Le coût de l’attente est invisible, et c’est pour ça qu’il gagne

La raison pour laquelle les équipes restent sur le papier, c’est que planifier semble productif et gratuit, alors que construire semble risqué et coûteux. Une série de prototypes coûte de l’argent réel. Cartes, pochoirs, assemblage, pièces qu’on n’utilisera peut-être qu’une fois. Rester en conception ne coûte rien qui apparaisse sur une facture.

Mais ça coûte du temps, et ça coûte la chose qui tue réellement les projets hardware : une assurance bâtie sur des hypothèses non testées. Chaque semaine où un design reste non construit, l’équipe s’attache davantage à des décisions que personne n’a validées. Quand la première carte arrive enfin, vingt choix couplés reposent dessus, et quand quelque chose cloche, vous ne pouvez pas dire lequel des vingt en est la cause. Construisez plus tôt, avec moins d’hypothèses empilées, et chaque défaillance pointe vers une seule chose.

Le coût invisible de l’attente dépasse presque toujours le coût visible d’une série de prototypes. Je n’ai jamais regretté d’avoir construit une carte grossière un mois plus tôt. J’ai régulièrement regretté l’inverse.

Le chemin pratique

Concrètement, cela ne veut pas dire « construisez tout le produit immédiatement ». Cela veut dire étager vos builds pour que chacun réponde aux questions auxquelles le papier ne peut pas répondre.

Commencez par nommer votre hypothèse la plus risquée. Pas le produit entier, la seule chose qui, si elle est fausse, coule le design. Peut-être que c’est de savoir si votre budget d’énergie survit à une charge réelle. Peut-être que c’est de savoir si un capteur précis performe dans votre environnement réel. Peut-être que c’est de savoir si votre lien radio tient à distance. Cette hypothèse a droit à son propre build, aussi petit que possible. Une carte de développement et un module breakout valent mieux qu’un PCB entièrement custom si ça répond à la question deux semaines plus tôt.

Gardez les premiers builds volontairement laids. Fils volants, retouches à la main, un boîtier qui est une impression 3D avec du ruban adhésif dessus. Dès que vous rendez un build joli, vous le ralentissez et vous vous y attachez. Le joli vient plus tard, une fois les questions de fond réglées.

Instrumentez tout ce que vous pouvez. La valeur d’un prototype est proportionnelle à ce que vous mesurez dessus. Des points de test, un UART libre pour le logging, un shunt que vous pouvez sonder pour le courant. Un prototype que vous ne pouvez pas mesurer vaut à peine mieux qu’un rendu.

Puis prévoyez la prochaine révision avant l’arrivée de la première. Il y aura une révision deux. Supposer le contraire, c’est ainsi qu’une carte unique se transforme en un marathon de débogage d’un mois sur du matériel que vous n’étiez jamais censé garder.

La version honnête

Personne ne réussit le hardware du premier coup. Ni les bonnes équipes, ni les expérimentées, ni celles aux gros budgets. La différence entre les équipes qui livrent et celles qui s’enlisent, ce n’est pas qu’un groupe évite les erreurs. C’est qu’un groupe amène ses erreurs sur un banc tôt, là où elles sont bon marché et lisibles, et que l’autre les traîne, invisibles et cumulatives, jusqu’à une série de production outillée où elles ne sont ni l’un ni l’autre.

Si votre projet est en phase de conception depuis un moment et qu’on s’y sent en sécurité, ce sentiment est le problème. La carte qui vous fait un peu peur, c’est celle que vous devriez commander.