J'ai appris à programmer sur un automate dans un hall d'usine, pas sur un MacBook dans une startup.
Chez Ranpak, je programmais des commandes Beckhoff pour des machines industrielles. Pas de hot reload, pas de console.log, pas de « on corrigera en production ». Quand un automate se trompait, un bras de 200 kilos partait dans la mauvaise direction.
Cette différence — entre un bug qui coûte une relance et un bug qui coûte de la matière — façonne encore chaque jour la façon dont j'écris du code.
Ce que j'ai appris sur le sol de l'usine
Avant Ranpak, j'ai travaillé chez Nedcar et O-I Manufacturing. Pas de code, mais la meilleure leçon que j'aie jamais reçue : si un processus ne fonctionne pas, c'est le système, pas les personnes.
Sur le sol de l'usine, on voit très précisément où ça coince. Des gens qui inventent des solutions de contournement parce que le logiciel gêne. Des processus qui existent « parce qu'on a toujours fait comme ça ». Des machines coûteuses à l'arrêt parce que personne n'a le temps de les faire fonctionner.
Quand j'ai plus tard redonné vie à une machine de découpe à 100 000 € chez Boogaard Textiles — non pas en bricolant la machine, mais en construisant le logiciel autour — c'était exactement ce que j'avais appris sur le sol de l'usine : regardez le processus, pas le problème.
Le pont vers le cloud
Chez Agron, j'ai appris le côté entreprise : la qualité des données à grande échelle. Un tableau de bord BI qui détectait plus de 30 000 erreurs dans les données ERP existantes. Là encore : pas un logiciel cassé, juste un processus qui n'avait jamais été bien configuré.
Aujourd'hui, je construis des plateformes web full-stack, des outils pilotés par l'IA et des intégrations d'API. La technologie est différente, mais l'approche est la même :
- Comprendre comment le travail circule vraiment — pas comment il est écrit sur le papier
- Trouver les frictions — où les gens inventent-ils des solutions de contournement ?
- Supprimer ces frictions — avec la solution la plus simple possible
Tous les développeurs ne savent pas programmer un automate. Mais chaque développeur devrait comprendre ce qui se passe quand son code touche le monde réel.
Ce que ça apporte
Cette combinaison est exactement ce qui rend Kerris ICT unique. Je sais comment fonctionne une usine et comment fonctionne une API. Je comprends pourquoi une machine coûteuse reste à l'arrêt — et je peux la réparer avec une API Laravel et un tableau de bord.
La plupart des développeurs construisent des fonctionnalités. Moi, je trouve les processus cassés et je les répare.