« Sait faire du Python » sur une ligne de production veut dire cinq choses précises : parler à un instrument, survivre à une panne matérielle sans planter le poste, faire tourner le code sur un PC de poste qui n'est pas un ordinateur portable, utiliser Git pour les changements et les releases, et faire remonter dans TofuPilot un run avec ses mesures et ses limites. Tout le reste est optionnel. Cette checklist présente les cinq, ce à quoi chacune ressemble au banc, et comment la vérifier en entretien ou en première semaine.
Les cinq compétences
Imprimez le tableau. Cochez-le en entretien, puis cochez-le à nouveau le vendredi de la première semaine. Un candidat honnête sur une lacune est plus utile qu'un candidat qui affirme maîtriser les cinq.
| Compétence | Ce que ça donne en pratique | Comment la vérifier |
|---|---|---|
| E/S instrument (PyVISA, SCPI, série) | Ouvre une ressource par adresse VISA, envoie *IDN?, convertit la réponse en float. Sait que write, query et read sont trois choses différentes. A utilisé pyserial pour une console DUT à 115200 bauds. | Entretien : donnez-lui l'adresse d'un DMM et demandez une lecture de tension continue au tableau blanc. Première semaine : il écrit un plug pour un instrument du banc et ce plug renvoie un nombre. |
| Exceptions autour du matériel | Met un timeout sur chaque ressource. Réessaie une requête capricieuse un nombre borné de fois. Ferme l'instrument dans close() même quand la phase a échoué. Rapporte une VisaIOError comme ERROR, pas comme FAIL. | Entretien : demandez ce que fait le poste quand le câble du DMM se débranche en plein run. Première semaine : débranchez le câble pendant sa phase et regardez. |
| Packaging et environnements | Crée un venv, fige les versions dans requirements.txt, installe sur un PC de poste Windows propre sans modifier PATH à la main. Sait que « ça marche sur mon portable » n'est pas terminé. | Entretien : demandez comment il amènerait le code sur un poste sans internet. Première semaine : il installe son poste sur le PC de rechange à partir du README seul. |
| Bases de Git | Crée une branche pour un changement, ouvre une pull request, obtient une revue, tague une release (v1.4.0) et sait dire quel tag tourne sur quel poste. | Entretien : demandez la dernière chose qu'il a annulée et comment. Première semaine : son premier changement de limite arrive sous forme de pull request relue, pas de fichier copié sur le partage réseau. |
| Flux de données | Déclare les mesures avec unités et validateurs dans procedure.yaml, lance avec --upload, ouvre la page du run de cette unité dans TofuPilot, lit le FPY et le Cpk sur la page de la procédure au lieu de construire un tableur. | Entretien : demandez ce qu'il ouvrirait en premier quand le rendement chute un lundi. Première semaine : il retrouve ses propres runs dans TofuPilot et vous explique une valeur de Cpk. |
Trois des cinq relèvent de l'hygiène logicielle ordinaire. Les deux qui distinguent un ingénieur de test d'un développeur généraliste sont les E/S instrument et les exceptions matérielles. Recrutez sur ces deux-là et enseignez les trois autres pendant la première semaine.
Les E/S instrument sont le point à creuser
Toutes les autres compétences s'apprennent dans un README. Les E/S instrument demandent un banc, un instrument qui ment, et quelqu'un qui s'est déjà fait avoir. Posez des questions sur les caractères de terminaison, sur une requête qui a renvoyé la réponse précédente, sur la différence entre un timeout GPIB et un timeout socket.
Les bons candidats ont une histoire pour chacune. La documentation PyVISA couvre la mécanique, et un candidat qui l'a lue le dira.
Les exceptions sont ce qui tue les postes
Une phase qui lève une exception et laisse le DMM à moitié configuré vous coûte l'unité suivante en plus de celle-ci. Attendez la réponse en trois parties : timeout à l'ouverture, réessai borné à la lecture, nettoyage à la fermeture.
Un except nu qui avale l'erreur, c'est ainsi qu'un poste rapporte PASS sur un câble débranché. Écoutez si le candidat fait la différence entre une unité qui a échoué et un poste qui a rencontré une erreur.
Ce dont ils n'ont pas besoin
Une fiche de poste qui liste tout ce que Python sait faire filtre les gens que vous voulez. Le guide de la fiche de poste traite de l'annonce elle-même. Voici la courte liste de ce qu'il faut laisser de côté.
| Pas nécessaire | Pourquoi |
|---|---|
| Frameworks d'interface (Tkinter, Qt, un front web) | L'interface opérateur est déclarée dans la procédure : champs texte, checklists, images, curseurs, progression. Pas de code front sur un poste. |
| Construire un séquenceur | Le framework exécute les phases dans l'ordre, injecte les plugs, gère depends_on et les slots multi-DUT. Un runner maison est la façon la plus courante de perdre six mois. |
| Construire des tableaux de bord | FPY, Cpk, cartes de contrôle, histogrammes et Pareto des défaillances sont dans TofuPilot. Un candidat qui propose un notebook pandas pour le rendement résout un problème que vous n'avez pas. |
| LabVIEW | Utile pour lire l'ancien poste pendant une migration, pas un prérequis d'embauche. Votre ingénieur LabVIEW lui fait visiter le diagramme une fois. |
| Python avancé (async, métaclasses, extensions C) | Un poste est un dossier de fonctions simples et de classes simples. S'il a besoin d'asyncio, c'est la conception du montage qui pose problème. |
Chaque usine a un tableau de bord de rendement maison qui ne s'ouvre que sur un seul PC, et la personne qui l'a construit est en vacances.
Auto-évaluation
Utilisez-la pour un candidat après le test technique à la maison, ou pour un ingénieur en poste qui prépare son propre passage de LabVIEW à Python. Niveau 2 sur toute la ligne, c'est un responsable de poste opérationnel. Niveau 3 sur une ou deux lignes, c'est un lead.
| Compétence | Niveau 1 | Niveau 2 | Niveau 3 |
|---|---|---|---|
| E/S instrument | Exécute un plug existant et lit la valeur | Écrit un nouveau plug à partir du manuel SCPI, gère la terminaison et les timeouts | Débogue un problème de bus avec une trace protocolaire, pilote un montage multi-instruments |
| Exceptions matérielles | Attrape l'exception et la journalise | Réessais bornés, nettoyage dans close(), ERROR et FAIL rapportés correctement | Conçoit le chemin de reprise : redémarrage électrique du montage, réinitialisation, reprise à la bonne phase |
| Packaging | Lance depuis un venv sur sa propre machine | Installe depuis requirements.txt sur un PC de poste hors ligne | Fige la version de Python, scripte l'installation du poste, conserve une image de référence qui fonctionne |
| Git | Commite sur main | Branche, pull request, revue, tag | Relit les autres, bissecte une régression, garde un dépôt par poste propre |
| Flux de données | Envoie un run et le retrouve dans TofuPilot | Déclare les limites dans procedure.yaml, lit le FPY et le Cpk par procédure | Lit une dérive sur la carte de contrôle, la relie à un montage ou à un instrument, livre le correctif en pull request |
Un développeur LabVIEW qui passe à Python est en général à 3 sur les idées derrière les E/S instrument et les exceptions dès le premier jour, et à 1 sur le packaging et Git. L'écart est plus court que ce que la plupart des managers imaginent.
Deux blocs qui valent la lecture
Les deux ont la taille du vrai code. Si un candidat sait les lire et dire ce qui casse quand on retire n'importe quelle ligne, il valide les deux premières lignes de la checklist.
Un plug avec un timeout, un réessai borné et un nettoyage dans close() :
plugs/dmm.py26 lines
# Plug multimètre : timeout à l'ouverture, réessai borné à la lecture, nettoyage dans close().import pyvisaclass Multimeter: def __init__(self, address="TCPIP::192.168.1.100::INSTR", retries=3): self.rm = pyvisa.ResourceManager("@py") self.inst = self.rm.open_resource(address) self.inst.timeout = 2000 # millisecondes self.retries = retries def read_voltage(self): last_error = None for _ in range(self.retries): try: return float(self.inst.query(":MEAS:VOLT:DC?")) except pyvisa.VisaIOError as error: last_error = error raise last_error def close(self): try: self.inst.write("*RST") finally: self.inst.close() self.rm.close()La phase qui l'utilise tient en deux lignes : def power_rails(measurements, dmm): measurements.rail_3v3 = dmm.read_voltage(). Les limites ne vivent pas dans la phase. Elles vivent ici :
procedure.yaml25 lines
# Une phase, une mesure. Les limites vivent dans la procédure, pas dans le code.name: PCBA Functional Testversion: 1.4.0unit: serial_number: default_value: "SN-000001" part_number: default_value: "PCBA-100"plugs: - name: dmm python: plugs.dmm:Multimetermain: - name: Power Rails python: phases.power_rails measurements: - name: rail_3v3 unit: V validators: - operator: ">=" expected_value: 3.2 - operator: "<=" expected_value: 3.4Lancez-la avec --upload et la mesure, ses limites et son résultat arrivent sur la page du run de l'unité dans TofuPilot. Le Cpk de rail_3v3 apparaît sur la page de la procédure dès qu'il y a assez de runs. Personne n'écrit cette partie.
Commencez par un poste
Choisissez le poste au plus gros volume, ou celui qu'une seule personne sait ouvrir. Reconstruisez-le en Python avec le TofuPilot Framework, puis faites-le tourner en parallèle de la version LabVIEW sur les mêmes unités pendant deux semaines. Les cinq compétences ci-dessus sont exactement ce que cette reconstruction exerce, dans l'ordre.
# Installer la CLI, lancer une procédure en local, puis la lancer avec upload.curl -fsSL https://www.tofupilot.app/install | shtofupilot run ./procedure.yamltofupilot run ./procedure.yaml --uploadLe guide de migration LabVIEW couvre la reconstruction étape par étape, et la page du Framework décrit l'organisation des fichiers. L'offre Lab est gratuite, et tofupilot run fonctionne sans compte.
