Un prototype peut demander un peu de cérémonie. On pose le Compute Module 5 sur une IO Board, on choisit le mode de boot, on branche l’USB au poste de travail, on lance rpiboot, puis on écrit l’image système ; pour un seul module, cette séquence ne pose pas vraiment de problème.4 Quand une caisse entière attend le même traitement, la manipulation de développeur commence pourtant à ressembler à une opération de fabrication.

Le Compute Module 5 Programming Jig rend ce changement d’échelle presque caricatural, parce que son intérêt se trouve moins dans le CM5 que dans tout ce qu’il construit autour. Le module nu tombe dans un logement défini mécaniquement, des pogo pins établissent le contact directement avec la carte, puis la fermeture du clamp déclenche le provisioning sans demander de monter une IO Board séparée.1

Gagner du temps est pratique, bien sûr, mais le déplacement principal se trouve ailleurs : une suite de gestes connue d’un développeur devient une opération qu’un autre humain peut refaire, surveiller et retrouver dans les logs.

Le geste disparaît

Le chemin de développement fabrique temporairement un petit système autour du CM5, avec sa carte porteuse, l’alimentation, le choix du boot, la liaison USB et les outils du poste hôte.4 Le jig déplace une partie de ce savoir dans la mécanique : quatre studs calent la carte, le couvercle impose la pression sur les contacts et un switch lié à la fermeture indique au logiciel que la cible est en place.1

Le travail de l’opérateur ne disparaît pas ; il se resserre autour de quelques gestes clairs, charger correctement le module, fermer la station, lire son état, puis retirer la carte au bon moment. Il n’a plus besoin de reconstruire la procédure technique complète à chaque passage, détail assez insignifiant avec une carte sur l’établi et beaucoup moins avec la quatre-vingt-dix-septième.

Des pogo fragiles

Les pogo pins ressemblent facilement au composant magique de l’histoire, jusqu’à la lecture des avertissements de Raspberry Pi. Les contacts sont délicats : fermer la station sans CM5 peut les endommager, un mauvais alignement peut tordre les pins ou faire rater le cycle, et retirer le module pendant le provisioning peut laisser la cible inutilisable.1

L’intérêt vient donc de la fixture entière. Le logement impose la position, les studs empêchent le mouvement latéral, le clamp applique l’effort et le logiciel relie l’état mécanique au début du cycle ; ce petit ensemble retire des choix à une opération qui sera répétée des dizaines ou des centaines de fois.

Un jig ne supprime jamais complètement l’erreur. Il déplace simplement une partie du jugement humain vers de la géométrie et des interlocks, endroits assez ennuyeux pour donner la même réponse toute la journée.

Trois sorties

Le logiciel utilisé derrière la station, rpi-sb-provisioner, complique aussi l’image mentale du « même disque copié cent fois ». Il sait installer un OS nu, chiffrer le stockage sans secure boot, ou combiner chiffrement et secure boot ; les artefacts IDP préparés à l’avance peuvent en plus décrire leur partitionnement et leur stockage.23

Dans les modes chiffrés, un secret matériel propre à l’appareil sert à dériver les informations nécessaires au déverrouillage du stockage. Le secure boot ajoute une étape irréversible : l’empreinte de la clé de signature du client est inscrite dans la mémoire OTP, de sorte que deux modules recevant la même image système ne sortent pas forcément avec un état cryptographique interchangeable.23

La nuance est importante. Une production cherche la cohérence entre les unités, alors que certaines données doivent précisément rester uniques à chacune d’elles.

L’irréversible

Dès qu’une opération touche à un état permanent, une commande maladroite coûte plus cher qu’un simple redémarrage du script. Le provisioner découpe donc son travail en phases de bootstrap, triage et provisioning, garde un état par numéro de série et écrit un journal propre à chaque appareil, notamment sous /var/log/rpi-sb-provisioner/<serial>/provisioner.log.3

La base de fabrication peut conserver numéro de série, adresses MAC, heure de passage et configuration de sécurité.2 Six mois plus tard, face à une unité revenue du terrain, l’équipe dispose ainsi d’une mémoire beaucoup plus utile qu’un vague « normalement on faisait comme ça » : elle peut retrouver ce qui a été appliqué à ce module précis.

Sur le prototype, toute la procédure peut tenir dans la tête de la personne qui l’a mise au point. Une production sérieuse finit par sortir cette mémoire de la tête humaine pour la mettre dans le système.

Quarante par heure

Raspberry Pi donne un chiffre de cycle assez parlant : pour une image de 2,6 Go en mode naked, le temps typique annoncé tourne autour de 1,5 minute par appareil, avec des variations selon la taille de l’image, le stockage et le réseau.1 Une tête qui fonctionnerait sans aucune manutention atteindrait donc un plafond arithmétique de 40 modules par heure, puisque 60 / 1,5 = 40.

Ce n’est évidemment pas une mesure de débit usine. Il faut ouvrir le clamp, changer la carte, contrôler l’état, gérer les échecs et accepter que les modes chiffrés réalisent davantage de travail qu’une installation nue.13 Le chiffre montre autre chose : dès que le geste devient un cycle, sa durée entre dans les paramètres d’ingénierie au lieu de rester une impression sur la vitesse de l’opérateur.

L’architecture logicielle sait faire tourner plusieurs provisionnements en parallèle,3 tandis que la station CM5 documentée par Raspberry Pi ne possède qu’une tête physique.1 Monter en cadence signifie donc aligner davantage de postes ou de têtes, pas convaincre la même boîte noire de programmer plusieurs modules par télépathie industrielle.

L’outil autour

Le Compute Module est conçu pour disparaître dans le produit de quelqu’un d’autre, et Raspberry Pi positionne depuis longtemps cette famille vers l’intégration commerciale et industrielle.5 Le Programming Jig montre la moitié beaucoup moins photogénique de cette promesse : une fois le module choisi, il faut encore décider comment chaque unité reçoit son logiciel, comment son état de sécurité naît, comment la fin du cycle est signalée et comment son historique sera retrouvé si la carte revient plus tard.

Aucune de ces décisions n’augmente la puissance du processeur, mais leur somme détermine si la centième unité peut vraiment être traitée comme la première. Le passage du prototype à la production se cache souvent dans cette couche autour du produit, faite de fixtures, d’interlocks, de logs et de numéros de série, là où les petits choix humains répétés finissent par devenir un processus capable de se souvenir de ce qu’il a fait.