Prototype ou projet d’ingénierie?
Réponse courte : tout dépend des conséquences possibles.
Tu travailles sur un projet ou un prototype qui pourrait bien être révolutionnaire pour la planète. Au début, c’est exploratoire : un banc d’essai, un modèle, un script, une preuve de concept, un montage qui fonctionne si personne n’éternue à côté.
Puis, le prototype commence à ressembler à quelque chose. On veut le brancher à un vrai procédé. Le tester sur le terrain. L’utiliser avec des données réelles. Le faire manipuler par des collègues. L’intégrer à un système.
Les choses s’accélèrent. On parle d’essais plus sérieux, d’un pilote, d’un client potentiel, peut-être même d’une mise en marché. Le projet n’est plus seulement une bonne idée dans un coin de labo : il pourrait se concrétiser dans le vrai monde. Yeah!
Et là, quelqu’un pète ta balloune avec une question où tu ne peux pas te dégonfler : est-ce qu’il y a des décisions techniques qui doivent être supervisées ou validées par un.e ingénieur.e?
Ce qui change tout : les conséquences possibles
Tant que tu testes une idée dans un cadre contrôlé (en labo, en atelier, dans un environnement de simulation ou avec des données fictives), tu peux encore casser, recommencer, comparer et apprendre sans exposer le vrai monde aux conséquences du prototype.
Mais dès qu’on veut passer au terrain, au pilote, à l’équipement réel, il faut prendre la mesure des conséquences possibles. Est-ce que quelqu’un peut se blesser? Est-ce qu’un équipement peut être endommagé? Est-ce qu’un procédé peut être déréglé? Est-ce qu’une décision peut être faussée? Est-ce que l’équipe de travail, un client, un patient ou le public peut être touché?
Si oui, certaines décisions techniques pourraient devoir être supervisées ou validées par un.e ingénieur.e. Le mot clé, ici, c’est conséquences. Pas le niveau d’enthousiasme autour du projet. Pas le fait qu’on l’appelle encore « prototype ». Ce qui compte, c’est ce qui peut arriver si ça fonctionne mal.
Ce qui peut exiger une validation
À ce stade, ce ne sont pas toutes les activités du projet ou autour du prototype qui deviennent soudainement réservées. Ce sont certains éléments techniques qui peuvent exiger une validation, par exemple :
- les charges, les seuils, les tolérances ou les facteurs de sécurité
- l’acceptabilité d’un résultat
- la conformité d’un système
- les conditions d’utilisation
- la logique qui contrôle un procédé
- la solution technique recommandée à partir des essais
| Situation | Usage prévu/ conséquence | Réflexe |
|---|---|---|
| Tu testes un capteur sur banc d’essai, en labo | Les résultats servent à comparer des options à l’interne. | Pas nécessairement une activité réservée. Documente tes essais et valide l’usage interne avec la personne qui te supervise. |
| Tu intègres un capteur à un équipement utilisé par une équipe. | Une mauvaise lecture pourrait provoquer un arrêt, endommager l’équipement ou mettre quelqu’un en danger.à | Fais valider les paramètres critiques par un.e ingénieur.e. |
| Tu codes un outil qui classe des données ou produit un tableau de bord. | L’outil aide à visualiser l’information, sans conclure à la conformité. | Pas nécessairement une activité réservée; assure-toi que l’usage de l’outil est clair. |
| L’outil que tu codes sert à conclure qu’un système est conforme ou non. | Le résultat influence une décision technique ou une certification. | Fais valider la logique et les critères par un.e ingénieur.e. |
| Tu développes un prototype mécanique en atelier. | Il reste en essai contrôlé, sans usage réel. | Tu peux continuer à tester, comparer et améliorer. |
| Le prototype que tu as développé sera branché à une machine ou à une chaîne de production. | Il peut avoir des conséquences réelles sur des personnes, des équipements ou un procédé. | Fais intervenir un.e ingénieur.e avant l’essai terrain. |
| Tu compiles des données de terrain. | Les données servent seulement à mieux comprendre la situation. | Activité pas nécessairement réservée. |
| Tu utilises des données pour recommander une conception, une implantation ou une mesure de sécurité. | Tu passes de l’observation à la recommandation technique. | Fais valider l’analyse par un.e ingénieur.e. |
Le réflexe à développer
Repérer le moment où le prototype ne sert plus seulement à apprendre, mais à décider, recommander ou valider quelque chose qui peut avoir des conséquences réelles.
La R-D sert à explorer, tester, rater, corriger et recommencer. C’est précisément ce qui la rend utile. Mais quand un prototype commence à sortir du labo, du dépôt GitHub ou du coin d’atelier, la bonne question n’est plus seulement : « Est-ce que ça marche? »
C’est aussi : « Qu’est-ce qui arrive si ça ne marche pas? »
C’est souvent là que se pose la vraie question d’ingénierie.
Voir aussi
Aide à la pratique
Tu peux créer ta startup en génie avant d’avoir ton permis
Oui, oui, tu peux devenir entrepreneur.e. Mais pas t’improviser ingénieur.e.
Aide à la pratique
Programmer un automate : coder ou faire de l’ingénierie?
Réponse courte : coder n’est pas décider de tout.
Aide à la pratique
Activités réservées : ce que tu peux faire sans court-circui...
Tu es CPI ou tu fais un stage en entreprise. Ton gestionnaire te demande de mettre à jour un plan avant son envoi a[...]