Corridor Confessions 4 – Le responsable industrialisation

Jérôme est responsable industrialisation chez 3D Juump. Si les logiciels sont impeccables, c'est sûrement grâce à lui. Découvrez ce que ce développeur méticuleux apporte à notre équipe.

"Parce que je suis quelqu'un d'assez consciencieux... rigide, diraient d'autres."

Ton parcours ?

J’ai fait une école d’ingénieur et puis je suis parti sur de la construction aéronautique. Pendant ma formation, j’ai bifurqué en informatique: un DEA en réseau, puis réalité virtuelle et augmentée. Je travaillais déjà un peu avec Sylvain (l’actuel manager de 3D Juump) et il m’a emmené chez 3D Juump. C’était il y a 10 ans.

Ton boulot aujourd'hui ?

Je suis responsable de l’industrialisation. Mon job, c’est de m’assurer que les logiciels qu’on sort respectent le cahier des charges et une certaine qualité. Parce que je suis quelqu’un d’assez consciencieux… rigide, diraient d’autres. Et puis je m’occupe aussi du développement JavaScript sur toute la partie API Web, qui est une librairie de programmation JavaScript utilisée par l’ensemble de nos produits sur le Web. Je chapeaute ça et je fais un peu de back end. Les outils de l’ombre, au final.

Quelles compétences ?

Pointilleux. Je pense que c’est un des aspects important du travail. C’est ce que j’essaye d’ailleurs de pousser aussi au sein de l’équipe, sur le fait d’être très rigoureux, de faire les choses de manière symétriques. J’ai fait un diplôme approfondi en réseaux et math. Peut être que ça vient de là.

Sur quoi travailles-tu en ce moment ?

On est en pleine livraison de la version 4.0 du logiciel. En ce moment, c’est surtout du bug fix, de l’augmentation des performances… des tâches de développement.

C'est quoi ce logiciel ?

C’est un visualisateur de bases de données 3D très grande. Il y a toute une partie metadata attributaire qu’on doit gérer, qui nous permet d’afficher une très grosse quantité de données 3D ou textuelles très rapidement. Cette base de données 3D peut représenter, dans l’industrie, une voiture, un avion, un train, un bateau qui va du moindre rivet à la grosse pièce en tôle pour des cas d’ingénierie, de documentation technique, de revue de projet. Le challenge, c’est de montrer tout ça en temps réel sur des machines qui ne sont pas super puissantes.

"Là, ce serait un petit un petit coup de poignard... "

Quelles sont les difficultés ?

Elles sont multiples. On a d’abord développé tous les logiciels en C++. Et puis on a souhaité développer une infrastructure, avec une partie serveurs pour ajouter des services. Puis on a développé une application et on est passé sur du web, pour la simplicité d’utilisation et l’accès par un navigateur. Donc la plus grosse difficulté, c’était un challenge de performance et migrer tout le code qu’on pouvait avoir ou utiliser plusieurs fils d’exécution qui étaient parallèles.

Après, il y a un autre point qui est finalement tout aussi important: C’est vraiment de bien comprendre le besoin de nos clients. On pense souvent être proche mais parfois on ne l’est pas. Et c’est quelque chose qu’on essaye d’améliorer tous les jours en essayant d’être à leur contact et de prendre leurs retours pour ne pas fournir qu’un superbe outil techno, mais vraiment de fournir un outil qui leur permette de gagner du temps. Et finalement, une des plus grandes satisfactions qu’on puisse avoir, c’est quand ils nous disent que le logiciel leur a permis de gagner 30% ou 50% sur leurs taches.
Et puis anticiper l’avenir, aussi, ce n’est pas simple. Ce sont des métiers qui prennent du temps, avec une historique de fonctionnement et même si on veut toujours faire évoluer le logiciel, il faut s’adapter aux contraintes de nos clients qui ont aussi besoin de temps pour faire évoluer les processus, la dépendance aux normes, les chaines de production et de validation…

Qu'est ce qu'un échec ?

Je n’ai pas l’impression qu’on ait des échecs. C’est juste qu’on ne réussit pas du premier coup. C’est souvent un processus itératif: On fait une première version qui est intéressante mais qui a encore quelques lacunes. Et puis on peaufine. En tout cas, on n’a jamais pris de direction qui aille à rebours des besoins de nos clients. En général, nous avons surtout des retours positifs. Même si on a eu quelques petits ratés à la livraison, c’était négligeable. Ca fait partie du cycle de vie d’un logiciel, mais on n’a jamais pris le risque de sortir une version non aboutie comme on peut le voir parfois, dans le monde des jeux vidéo.

Le pire qui puisse arriver ?

Q’une IA me remplace ? Non… je dirais: que les clients nous disent qu’ils ont trouvé ailleurs quelque chose qui est encore bien meilleur que ce qu’on a fait. Là, ce serait un petit un petit coup de poignard…

Yet another framework ?

Haha oui, il y a toujours le nouveau langage qui va sortir et qu’il va falloir implémenter, la nouvelle librairie qu’il va falloir tester. En web, il y a beaucoup de frameworks qui sortent très vite et qui ont la hype. Mais j’ai de la chance: au niveau des briques de base qu’on fournit, il n’y a aucun outil incroyable qui est utilisés. C’est vraiment le truc de base et j’ai une certaine stabilité à ce niveau là. Par contre, c’est vrai qu’au niveau applicatif, on peut avoir certaines tentations de repartir sur des trucs complètement nouveaux. Et puis six mois après, on se rend compte que c’est mort, par exemple.

"Donne un poisson à un homme, on nourrit pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours"

Qu'est-ce que tu fais quand ça ne marche pas ?

Je râle. J’essaye de trouver qui pourrait être responsable à part moi. J’appelle les équipes et je les tape. Non: tout simplement j’essaye de faire en sorte que ça fonctionne. Ça peut aller vite comme ça peut aller assez lentement. Là, dans la dans la nouvelle version du logiciel, on a fait la révolution sur beaucoup de choses, et il a fallu reconstruire pas-à-pas.

Il y a un collègue qui m'a dit que quand on a posé une question technique, il fallait prévoir à peu près 1 h devant soi. Comment expliques-tu cela ?

Ha! La fourberie. En fait, j’aime bien enseigner, je trouve que si on est là sur cette terre, c’est pour transmettre quelque chose. Et effectivement, plutôt que de donner la réponse, j’essaye beaucoup plutôt de faire comprendre pourquoi c’est la bonne réponse. C’est vrai que ça peut prendre du temps. C’est un peu l’adage « donne un poisson à un homme, on nourrit pour un jour. Apprends-lui à pêcher, tu le nourris pour toujours ». Voilà, c’est complètement cette idée là qui m’anime.

Quelque chose à dire à propos du Coca ?

Que c’est quelque chose qu’il faudrait que j’arrête. Je tiens à préciser quand même que c’est du Coca 0. Sinon je serais beaucoup plus gros. Après oui, je sais, c’est quelque chose qu’il faut que je limite, mais c’est ma caféine à moi. Mais pour l’instant, c’est compliqué…

the future of work instructions

3D Juump Kiwi, le futur de la rédaction technique

Les départements assemblage et maintenance sont désormais connectés à la maquette, en temps réel. Un gain de productivité énorme pour les rédacteurs techniques. Le futur de la rédaction technique Créez pas-à-pas des procédures de maintenance

Read More »

Partagez-le sur …

LinkedIn
Twitter
Facebook
Email
Retour en haut
request a demo of 3D juump KIWI

In the context of the new European regulation on the protection of personal data, the collection and processing (by us) of your personal data requires your consent for each purpose. The Customer Support department has IT resources to manage requests for information more easily. In accordance with the “Informatique et Libertés” law of 6 January 1978, you have the right to access and rectify information concerning you, which you can exercise by contacting REAL FUSIO – Customer Support Service – 9 boulevard Henri Ziegler – 31705 Blagnac. You can also, for legitimate reasons, oppose the processing of data concerning you..