Guillaume Robin, Head of Software Engineering « Si tu résumes le métier à écrire du code, tu passes à côté de l’essentiel »
Guillaume Robin, Head of Software Engineering « Si tu résumes le métier à écrire du code, tu passes à côté de l’essentiel »
Guillaume a grandi avec une vraie obsession de comprendre comment les choses fonctionnent. Après des études d’ingénieur à l’Epita puis à Epitech, un double diplôme en computational intelligence à Kent University et un passage par la Banque de France et le freelancing, il rejoint Inarix, une deep-tech qui transforme un téléphone en mini-laboratoire capable d’évaluer la qualité des grains agricoles.
On a parlé d’IA « pour de vrai », d’analyseurs de grains à 20 000 euros remplacés par un smartphone, de compromis techniques, de remote intégral, de management et de ce que l’IA change vraiment dans le métier d’ingénieur.
Premiers pas dans l’IA
« J’ai fait Epita puis Epitech, avec un double diplôme en computational intelligence. Aujourd’hui tout le monde parle d’intelligence artificielle, mais à l’époque on parlait surtout de machine learning. »
Très vite, il se rapproche du labo d’Epitech.
« Je me suis retrouvé au Hub Innovation, dans le département IA. J’ai fini par y faire des cours. C’est vraiment là que mon intérêt pour l’IA a pris forme. »
La suite passe par un stage à la Banque de France, puis des missions freelance. C’est là qu’il croise la route d’Inarix.
« Ils cherchaient quelqu’un pour transformer une infra “un client, un modèle” en une vraie plateforme multi-clients, multi-modèles. Le MVP était validé. Mon rôle, c’était de prendre tout ce qui existait et d’en faire quelque chose qui pouvait passer à l’échelle. »
Rencontre avec Inarix et déclic deep-tech
« Quand j’arrive, il y a le CEO, Pierre, un premier data scientist, Helmi, Artemis le CTO, et quasiment en même temps Alexandre, Head of Data Science. Lui s’occupe des modèles, moi du software et de l’infrastructure. »
Ce qui l’accroche n’est pas seulement la technique.
« Ils avaient déjà prouvé quelque chose de fort : à partir d’une simple photo, un téléphone pouvait analyser la qualité d’un échantillon de grains. Pas besoin de machines à plusieurs dizaines de milliers d’euros. C’était rapide, concret, et surtout utile. »
Le sérieux de l’équipe compte tout autant.
« Pierre était ultra carré sur la finance. Artemis maîtrisait parfaitement la vision technique. Tu sens quand une équipe est solide. Et puis l’impact était immédiat : mieux évaluer la qualité, c’est mieux rémunérer les agriculteurs. J’ai senti que ça marcherait, à condition de beaucoup travailler. »
Contexte 2020.
« À l’époque, peu de monde entraînait ses propres modèles. Les clouds n’étaient pas encore optimisés pour l’inference sur GPU, on parlait très peu des foundation models… tomber sur une équipe qui voulait tout faire en interne, c’était rare. C’est aussi ce qui m’a convaincu. »
Expliquer Inarix à un CTO
« Dans l’agriculture, tout tourne autour de la qualité des grains. Trois acteurs : les producteurs, les collecteurs, les transformateurs. Historiquement, l’analyse se faisait avec des machines coûteuses et lentes. »
La promesse d’Inarix tient en un changement d’échelle.
« Ce qu’on fait, c’est amener cette analyse dans un téléphone. L’opérateur prend une ou deux photos, et on calcule automatiquement les critères nécessaires, variété, taux de protéines, etc. Ça lui permet de décider en quelques secondes dans quel silo stocker, et d’éviter des erreurs qui peuvent coûter très cher. »
Promesse vs réalité terrain
« Aujourd’hui, la promesse est tenue. On est déployés dans beaucoup de silos, et la rapidité du téléphone a convaincu. »
Mais la transition n’a pas été évidente.
« Dans un silo, il y a souvent une machine historique, chère et “officielle”, à laquelle tout le monde fait confiance. Dire que le téléphone fait aussi bien, c’est un choc. Il a fallu prouver la performance. »
Les comparaisons systématiques avec les standards ont joué un rôle décisif.
« On envoyait régulièrement des échantillons en labo tiers. Et plusieurs fois, quand nos résultats différaient de ceux des machines, c’est nous qui avions raison. Ça change immédiatement la discussion. »
La confiance s’est installée progressivement.
« Aujourd’hui, les clients s’appuient énormément sur nous. Ça montre que nous sommes devenus central dans leur process. »
Premiers gros défis techniques
« Quand j’arrive en janvier 2020, un freelance avait déjà posé une infra. Elle n’était pas extensible. On avait une web app, une app mobile, des serveurs, des outils d’entraînement de modèles… et il fallait que tout soit prêt pour début juin. Et j’étais seul côté software. »
La décision est radicale.
« On a quasiment tout refait. On a gardé une partie de la web app, mais pour le reste, on a décidé de repartir de zéro. C’était un défi technique et organisationnel énorme, mais c’était la bonne décision. Refaire tôt coûte toujours moins cher qu’empiler sur de mauvaises bases. »
Vient ensuite le sujet de l’inférence.
« L’enjeu suivant, c’était l’infrastructure d’inférence. C’est ce qui met les modèles à disposition des clients. Le GPU coûtait cher, il n’y en avait pas beaucoup, et on n’avait pas un budget infini. Il fallait une solution capable d’aller chercher des machines chez différents fournisseurs, d’optimiser les coûts, tout en encaissant les pics de la récolte. À l’époque, très peu d’équipes se construisaient leur propre système d’inférence. Beaucoup passaient par des services sur étagère et y mettaient simplement plus d’argent. »
Sur la précision, la barre reste haute.
« On n’a jamais fait de compromis sur la précision. En agriculture, le moindre pourcentage compte. Là où on a fait des compromis, c’est sur la vitesse à laquelle on livrait certaines choses, ou sur le fait d’accepter parfois une solution moins élégante à court terme. Sur la qualité du résultat, on a toujours voulu être au mieux de ce que la science permettait. »
Décisions techniques qui ont tout changé
Il cite deux décisions fondatrices.
Première décision : changer radicalement l’architecture des modèles.
« Suite à des nouveautés dans le domaine, Alexandre a décidé de revoir complètement la manière dont on construisait les modèles. Pendant un an, les nouvelles architectures n’atteignaient pas la performance des anciens modèles. C’était très risqué. Mais à partir du moment où ils ont trouvé la bonne recette, on a explosé les performances. Sans ce pivot, on n’aurait probablement jamais atteint le niveau actuel. »
Derrière, il y a des architectures modernes et beaucoup de savoir-faire d’entraînement.
« Aujourd’hui, il y a du transformer dans l’histoire, mais ce n’est pas juste un modèle. C’est une sauce d’entraînement, des choix de données, des réglages. Et cette sauce évolue en permanence. »
Deuxième décision clé : la manière de collecter les données sur le terrain.
« Dès le début, quand j’ai refait l’app mobile, on a décidé de faire un système générique de collecte, un peu comme un Google Forms embarqué. L’opérateur déclare ce qu’il reçoit, la variété, l’espèce, et on peut lui demander d’autres infos comme l’humidité ou la température. Ce système est configurable côté serveur, pour s’adapter à la réalité de chaque client sans développer de nouvelles choses à chaque fois. »
Cette vision data-driven paye sur le long terme.
« Comme on a catégorisé et structuré les données dès le départ, on a construit en quelques années une base incroyablement riche. Et surtout, on a pu adapter les formulaires au business, en temps réel, sans casser la chaîne de données. Ça nous a évité des mois de travail de catégorisation plus tard. »
Construire une équipe : data, software, QA
L’organisation de la tech s’affine au fil des années.
« Côté data, chaque data scientist avait un sujet, parfois à plusieurs, avec une logique très recherche. Côté software, on a progressivement structuré autour de l’infra, du mobile, du web, du backend, du data engineering, puis de la QA. »
Guillaume reste au centre du backend et du management.
« Ma base, c’est le backend. On a d’abord recruté sur l’infra/DevOps, puis mobile, puis web, puis data engineering, puis à nouveau backend. Ensuite, on a ajouté un deuxième data engineer, une deuxième personne sur l’infra, une équipe QA, un lead mobile, un lead data engineer. Moi, je gardais le backend tout en pilotant l’ensemble. »
La R&D est très clairement côté data.
« La vraie R&D, c’est côté modèles. Nous, en software, on rend tout ça utilisable, stable, industrialisé. Mais on s’est rendu compte qu’on ne pouvait pas séparer les mondes complètement. À un moment, on a donné aux data scientists la possibilité de déployer eux-mêmes en production, pour qu’ils comprennent les contraintes réelles et qu’on parle le même langage. »
Deux cultures d’ingénierie à faire cohabiter
« Tu as une culture recherche, très rapide, très expérimentale, et une culture software, beaucoup plus lente parce qu’il y a des process de qualité, de sécurité, de fiabilité. Les deux sont légitimes, mais les faire cohabiter n’est pas trivial. »
Au début, chacun reste trop dans son silo.
« Pendant un temps, les data scientists exportaient un modèle et ensuite ce n’était plus leur responsabilité. L’équipe software le mettait en prod. Ça créait de l’opacité, de l’incompréhension. Quand il y avait un problème, c’était toujours: est-ce que c’est la data ou le software ? »
La solution passe par le partage de responsabilités.
« Le déclic, ça a été d’ouvrir l’environnement de prod aux data scientists, qu’ils puissent tester dans les mêmes conditions que leurs modèles en recherche. Et nous, côté software, on s’est mis à tester aussi dans leurs conditions. Quand chacun voit le monde de l’autre, les frictions baissent. »
Full remote très tôt, et ce que ça change vraiment
Avec le Covid, Inarix bascule en full remote alors que la culture présentielle n’a pas eu le temps de s’installer.
« C’était la meilleure décision possible. La boîte était jeune, il n’y avait pas encore d’habitudes de bureau très ancrées. Par contre, il faut accepter que le remote, ce n’est pas “la même chose mais à distance”. Il faut une culture de la communication écrite. »
Les règles qui émergent sont simples mais exigeantes.
« Quand tu fais une réunion orale, quelqu’un doit prendre des notes et les partager. Quand tu dis “on s’appelle” dans un thread Slack, il faut faire un résumé après. Sinon, ceux qui n’étaient pas là sont perdus. À distance, si ce n’est pas écrit, ça n’existe pas. »
Le remote ouvre aussi les frontières.
« Ça nous a permis de recruter partout en France, puis à l’étranger. On a eu un stagiaire qui ne parlait pas français, qui est passé en CDI. On a basculé toute la communication en anglais. Ça a ouvert l’accès à des profils qu’on n’aurait jamais pu recruter autrement. »
Mais tout le monde n’est pas fait pour le full remote.
« On a vu des gens réaliser au bout de trois mois qu’ils se sentaient seuls, que ce mode de travail n’était pas pour eux. Il y a des “cicatrices” du présentiel qui mettent du temps à disparaître. Par exemple, demander une demi-journée pour aller chez le médecin. Il a fallu répéter : tu bloques ton agenda, tu y vas, et tant que le boulot est fait, ça va. C’est un changement de d’état d’esprit. »
Recruter en remote sur des sujets durs
Le rôle le plus difficile à recruter : infra/DevOps.
« On a mis un an et demi à trouver. Beaucoup de profils étaient soit trop juniors, soit très expérimentés mais sur des environnements propriétaires qui ne collaient pas à nos besoins. Et on devait aussi filtrer la capacité à travailler à distance. »
Les juniors, eux, sont exclus par le contexte.
« En full remote, avec une petite équipe et des enjeux très durs, on ne peut pas se permettre de prendre des profils très juniors. Il faut de l’autonomie, de la discipline. Ce n’est pas le modèle idéal pour un premier job. »
Il n’y a pas de recette magique pour détecter quelqu’un de “remote compatible”.
« Avoir une expérience précédente en remote aide. Mais au-delà de ça, c’est beaucoup de ressenti : comment la personne écrit, comment elle structure ses réponses, comment elle se comporte en visio. Et ensuite il reste le seul vrai test : la période d’essai. »
Ce qui distingue un très bon ingénieur
« Je n’aime pas le micromanagement. Je recrute des gens qui n’attendent pas qu’on leur dise quoi faire. Ils doivent être capables d’aller chercher le besoin, de prendre des initiatives, de comprendre les grandes directions. »
La vision produit et business devient centrale.
« Avec les IA qui codent, la différence ne va pas se jouer sur le fait d’écrire du code. Elle va se jouer sur la compréhension du problème métier. Un bon ingénieur doit comprendre pourquoi, pour tel modèle, on n’a pas besoin de perfection tout de suite. Qu’un modèle “suffisamment bon” apporte déjà énormément de valeur, et que l’entreprise a besoin de vendre, de survivre. »
Savoir dire non fait partie du job.
« En startup, tout le monde fonce. Tu as besoin de gens capables de lever la tête, de dire non, et d’argumenter pour protéger l’entreprise de décisions techniques qu’elle paiera plus tard. Même si, au final, on ne suit pas toujours leurs recommandations, au moins on ne pourra pas dire que personne n’avait prévenu. »
Apprendre à être manager
« Je n’ai pas vraiment choisi d’être manager. J’ai accepté. On s’était mis d’accord avec le CTO : si ça ne me plaisait pas, il faudrait trouver une autre solution. Au final, j’ai adoré, mais dans un cadre précis. »
Premier apprentissage : déléguer.
« Comme beaucoup de gens arrivés tôt, j’ai dû accepter que d’autres touchent à ce que j’avais construit. Sur le mobile ou le front, aucun problème. Sur le backend, ça m’a demandé plus de temps, parce que je sais que c’est le coeur. Mais si tu ne délègues pas, tu bloques tout le monde. »
Ensuite vient la gestion des différences individuelles.
« Tu ne manages pas tout le monde pareil. Certains ne perdent jamais confiance, ils vont au front tout le temps, parfois trop vite. D’autres doutent beaucoup, il faut les accompagner jusqu’à ce qu’ils prennent confiance. Certains encaissent très bien les feedbacks directs, d’autres ont besoin de plus de nuances. Tu dois t’ajuster. »
La résolution de conflit est souvent plus simple qu’on ne le croit.
« À distance, beaucoup de conflits naissent d’un message mal interprété. Mettre les deux personnes dans le même call, les faire parler, règle 90 % des problèmes en cinq minutes. »
Enfin, il voit le rôle du manager comme un tampon.
« Je me suis toujours vu comme un filtre. Mon job, c’est d’encaisser, de filtrer les demandes et de ne transmettre à l’équipe que ce qui a un vrai impact. Le développement demande de longues plages de concentration. Envoyer un message directement au développeur pour chaque idée, ça détruit ça. Donc oui, tu prends un peu plus de charge, mais c’est le rôle. »
Futur d’Inarix, futur ailleurs
Côté Inarix, un nouveau produit a été lancé autour de la traçabilité dans la supply chain.
« L’idée est de mapper les sites de stockage, silos compris, et de savoir en temps réel ce qu’il y a dedans, en quantité et en qualité. Avec le développement du stockage à la ferme, les coopératives louent de plus en plus de capacité chez les agriculteurs. Elles doivent garder une vision claire sur des silos qui ne sont plus physiquement chez elles. »
Le défi est autant produit qu’humain.
« C’est un produit complexe, sur un sujet où beaucoup se sont cassé les dents. Et en parallèle, l’équipe a beaucoup donné pendant des années. Il y a de la fatigue, des restructurations, des départs. Repartir dans une logique “retour au début, nouvelle promesse, nouveau marché” demande énormément d’énergie. »
Pour Guillaume, le prochain chapitre se situera ailleurs.
« Inarix est à un moment où le market-fit n’est plus à prouver sur les premiers produits, mais qu’il faut stabiliser, viser la rentabilité, clarifier si l’objectif est de devenir une belle PME rentable ou de repartir pour une trajectoire plus agressive sur de nouveaux produits. Moi, j’avais envie de voir l’étape d’après : une entreprise qui a déjà trouvé son product market fit, qui passe de 30 à 80 ou 100 personnes, qui lance un deuxième produit, qui se structure vraiment à l’échelle. »
Il rejoint ainsi une autre entreprise plus avancée dans sa trajectoire, pour prendre le lead sur un nouveau produit.
Avoir fait de l’IA “pour de vrai”
« Le gros avantage pour moi, c’est d’avoir travaillé sur des modèles entraînés en interne, pas juste sur des API. À l’époque, ceux qui entraînaient vraiment leurs modèles, c’étaient Google, Facebook et quelques labos. Aujourd’hui, beaucoup de boîtes “font de l’IA” en appelant l’API d’un tiers. Ça marche, mais ce n’est pas la même expérience. »
Cette expérience lui donne une vision différente du marché actuel.
« Je vois beaucoup d’entreprises qui font du juridique assisté par IA, de la rédaction, des copilotes métiers. Techniquement, elles sont très dépendantes d’un fournisseur. Elles n’ont pas toujours les compétences en interne pour comprendre les limites du modèle, ses biais, ses coûts, sa sécurité. Le risque, c’est de subir la technologie plutôt que de la maîtriser. »
Pour autant, tout le monde n’a pas vocation à entraîner ses modèles.
« Quand tu parles de LLM ou de VLM, les coûts d’entraînement sont énormes. Tu ne recrées pas en cinq ans ce que des boîtes ont construit en dix avec des centaines de millions de budget. Il faut choisir ses batailles. Parfois, payer une API reste la meilleure option. Ce qui compte, c’est de le faire en connaissance de cause. »
L’IA va-t-elle remplacer les développeurs ?
« Je pense que l’IA va surtout faire monter le niveau moyen. Elle va être très bonne pour produire du code “correct”, dans la moyenne. Ceux qui sont en dessous de ce niveau moyen vont souffrir. Ceux qui sont au-dessus, qui comprennent le métier, l’architecture, les contraintes, vont être augmentés. »
Pour lui, la clé est de distinguer développeur et software engineer.
« Depuis longtemps, je fais la différence entre développeur et software engineer. Les développeurs aiment le code. Les software engineers aiment comprendre le système, le problème métier, la science derrière. Ce n’est pas le même état d’esprit. »
Les profils uniquement attirés par le code risquent de plus fréquemment se heurter à l’IA.
« Si tu n’aimes pas spécialement le métier derrière, que tu ne cherches pas à comprendre comment ça marche, et que tu vois le code comme une fin en soi, tu te retrouves en frontal avec des modèles qui, eux, génèrent du code toute la journée. Ceux qui vont le plus utiliser les LLM pour coder seront souvent ceux qui n’aiment pas vraiment le code. C’est un peu paradoxal. »
Il ne voit pas l’IA comme un remplacement, mais comme un révélateur.
« Si tu aimes comprendre le métier, démonter le stylo pour voir comment il est fait, chercher une solution élégante à un problème complexe, l’IA va te retirer une partie pénible du travail. Elle va générer du boilerplate, des endpoints répétitifs, des premiers drafts. Mais elle ne remplacera pas ce que tu mets dans la conception, dans les choix, dans l’arbitrage. Pas tout de suite en tout cas. »
Ce qu’il dirait à un jeune qui veut se lancer
« On a beaucoup vendu le métier de développeur en disant que tu pouvais y arriver en six mois. Tu peux apprendre à coder vite, oui. Mais l’informatique, c’est une science qui a des décennies d’histoire. Tu ne l’ingères pas en un bootcamp. »
Pour lui, la question à se poser est simple.
« Est-ce que tu veux vraiment passer tes journées à comprendre des systèmes, des métiers, des contraintes, et pas juste apprendre un langage à la mode ? Si la réponse est oui, tu as une place. Si c’est juste pour l’argent, ou parce qu’on t’a dit que “dans la tech il y a du boulot”, ça va être très dur de tenir la cadence. »
Et il rassure ceux qui sont déjà dans le métier.
« L’IA ne va pas remplacer du jour au lendemain les bons ingénieurs. Elle va rendre le métier plus exigeant. Il faudra rester devant la moyenne, continuer à apprendre, à comprendre ce qu’on fait. Mais si tu ne résumes pas ton travail à taper du code, tu as encore de la marge. »
