Programmer un automate : coder ou faire de l’ingénierie?
Réponse courte : coder n’est pas décider de tout.
Tu travailles sur un automate, un outil d’optimisation, un script de contrôle, un modèle d’IA. Tu codes. Tu testes. Tu ajustes. Tu règles des bogues.
Pour toi, c’est clair : tu codes. Tu programmes en langage Ladder, tu configures des tags, tu relies un écran HMI, tu fais communiquer l’automate avec une API ou tu règles un bogue dans une séquence. Bref, pas besoin de sortir le grimoire de la Loi sur les ingénieurs.
Puis, quelqu’un te demande de modifier un setpoint, d’ajouter un interlock, de changer les conditions de démarrage, de toucher à une séquence ESD ou de décider ce qui doit déclencher une alarme.
Là, ce n’est plus seulement une question de syntaxe, de logique de code ou de bouton qui fonctionne. Quand tu choisis comment le procédé doit réagir, tu ne fais pas juste « pondre du code »…
Ce qui est réservé : définir la logique
Dans un procédé industriel, la logique de contrôle n’est pas un détail technique caché dans le code. C’est ce qui détermine comment le procédé se comporte : quels seuils déclenchent une alarme, quelles conditions permettent ou empêchent un démarrage, quels dispositifs de verrouillage forcent un arrêt, quelles étapes doivent s’enchaîner.
Cette logique doit être définie ou validée par une ingénieure ou un ingénieur parce qu’elle influence directement la façon dont l’équipement ou le système fonctionne et réagit.
Ce qui n’est pas réservé : programmer ce qui est déjà défini
Une fois cette logique établie, la programmation elle-même n’est pas une activité réservée. Si un.e ingénieur.e a préparé les directives, les paramètres ou la description fonctionnelle, une personne avec les connaissances techniques nécessaires peut coder ce qui a été défini.
Autrement dit : écrire le code n’est pas toujours l’enjeu. L’enjeu, c’est de savoir qui a décidé ce que le code doit faire.
| Tu fais quoi? | Réflexe |
|---|---|
| Tu programmes un automate à partir d’un algorithme établi. | Généralement OK. |
| Tu corriges un bogue d’interface. | Généralement OK. |
| Tu modifies un seuil d’alarme. | Est-ce qu’un.e ingénieur.e a validé le nouveau seuil? |
| Tu changes une séquence automatisée. | Est-ce u.ne ingénieur.e qui a défini le déroulement de la séquence? |
| Tu ajoutes un interverrouillage. | Est-ce un.e ingénieur.e qui en a validé les conditions? |
| Tu prépares une description fonctionnelle. | Direction et surveillance immédiates requises. |
| Tu décides quand un système doit s’arrêter. | À faire valider par un.e ingénieur.e. |
Quand ce n’est plus juste de la programmation
Tu n’as pas à te poser mille questions chaque fois que tu ouvres ton éditeur de code. Mais tu devrais poser la question si on te demande de modifier la logique du procédé, de fixer un seuil, de changer une condition d’arrêt, d’ajouter une séquence automatique ou de décider ce qui est sécuritaire ou acceptable.
La question à te poser est simple : « Est-ce que cette logique a été définie ou validée par un.e ingénieur.e? »
Ton scrum master peut t’aider à gérer le sprint. Pas à trancher une question d’activité réservée. Pour savoir si une décision technique doit être supervisée par un.e ingénieur.e, adresse-toi à la personne qui te supervise ou à l’ingénieur.e responsable du projet. Et si la réponse reste floue, l’Ordre peut aussi t’aider à y voir clair.
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
Prototype ou projet d’ingénierie?
Réponse courte : tout dépend des conséquences possibles.
Aide à la pratique
CPI : avant de s’appeler ingénieur.e
Tu termines ton bac, tu accumules les stages, tu as peut-être des certifications et même quelques projets solides à[...]