Nicolas Henocque

Mes premières expériences techniques remontent à l'adolescence, autour des environnements multijoueurs : j'y construisais des extensions, des fonctionnalités, des services communautaires et les outils qu'appelaient leurs usages. Il fallait aussi administrer les serveurs qui les hébergeaient, tenir leur disponibilité et répondre aux incidents des communautés qui s'en servaient. J'ai compris très tôt qu'un logiciel ne vit jamais dans un environnement parfaitement contrôlé : il dépend de son exploitation, des ressources disponibles et de la manière dont les personnes se l'approprient.

Cette pratique a structuré ma façon de travailler. Chaque projet révélait une limite dans mes connaissances et me donnait une raison concrète de la dépasser. Je réutilisais les principes qui avaient fait leurs preuves, je cherchais la cause d'un problème avant d'en traiter les symptômes et je faisais évoluer mes solutions plutôt que de repartir systématiquement de zéro. Mon parcours s'est construit selon cette logique progressive : apprendre ce qui manque pour répondre à un besoin réel, en éprouver la compréhension par la réalisation, puis conserver cet acquis pour aborder un périmètre plus large.

Mon entrée à l'université a donné une structure théorique à cette pratique déjà ancienne. La formation accordait une place importante aux projets, qui obligeaient à mobiliser plusieurs notions dans une réalisation complète. La licence, puis le master, m'ont permis de mettre des concepts, des méthodes et un vocabulaire précis sur des mécanismes que j'avais parfois compris de manière intuitive. Je ne cherchais plus uniquement à produire une solution fonctionnelle : je devais être capable d'en expliquer l'organisation, de justifier mes choix et d'anticiper la manière dont elle pourrait évoluer.

En parallèle, j'ai mené mes premières missions de développement rémunérées, avant de structurer ma propre activité. Elles confrontaient immédiatement mes acquis à un engagement professionnel : comprendre une demande, distinguer le besoin réel de sa première formulation, concevoir une réponse exploitable et rester disponible après sa livraison. L'université apportait la méthode ; l'entrepreneuriat vérifiait chaque semaine que cette méthode résistait à la réalité.

À mesure que mon activité se développait, le bouche-à-oreille et les recommandations ont constitué le principal moteur de mon portefeuille de clients. Cette confiance reposait sur une manière de travailler qui s'était affirmée avec l'expérience : écouter avant de conseiller, expliquer les choix et rester présent lorsque la solution rencontrait les contraintes du quotidien. Plusieurs de ces relations se sont inscrites dans la durée, parce que les entreprises savaient qu'elles obtiendraient un avis proportionné à leur situation plutôt qu'une technologie ou une prestation ajoutée par réflexe.

Les besoins accompagnés se sont alors élargis : développement d'outils métiers, évolution des équipements et des infrastructures, coordination de prestataires et organisation progressive du système d'information. Par confidentialité, je ne publie ni le nom de mes clients ni les informations propres à leur activité : ce n'est pas une limite à la présentation de mon travail, c'en est l'une des responsabilités. Je présente donc ce qui relève de la mienne : comprendre le fonctionnement de l'entreprise, rendre les décisions lisibles, conduire leur mise en œuvre et préserver la capacité du client à faire évoluer son environnement sans devenir dépendant d'une succession d'intervenants.

Cette période universitaire et entrepreneuriale ne constitue pas seulement le début de mon activité : elle a construit ma manière de raisonner. Chaque projet m'a conduit à élargir le précédent, du développement vers l'exploitation, du fonctionnement technique vers les usages, puis des usages vers l'organisation de l'entreprise. Elle m'a également appris à ne pas avancer sur la seule base d'une intuition : comprendre, réaliser, observer les conséquences et conserver ce qui mérite de l'être.

C'est dans cette continuité qu'a progressivement émergé mon rôle de DSI externe. Il ne s'agissait plus uniquement de répondre à un besoin ponctuel, mais de relier les décisions, les outils, les intervenants et les contraintes dans une même trajectoire. Cette expérience de proximité est restée active pendant toute la suite de mon parcours.

Le tutorat s'inscrit dans la même logique de validation que mes projets techniques. J'avais bénéficié, à l'université, d'enseignants capables de donner du relief à des notions abstraites et de montrer le raisonnement qui mène à une solution. J'ai voulu éprouver à mon tour ma capacité à transmettre avec précision et à rendre compréhensible la réflexion derrière les notions techniques. Pendant plusieurs mois, j'ai accompagné chaque semaine un étudiant en BTS sur les fondamentaux de la programmation, de l'algorithmique et du développement web, notamment en Java et PHP. J'ai construit un programme personnalisé associant rappels de cours, exercices gradués, évaluations et mini-projet, afin de proposer un cadre exigeant, progressif et lisible.

L'objectif était de combler les lacunes sans réduire l'accompagnement à la correction d'exercices. Je cherchais à comprendre la logique suivie par l'étudiant, à repérer le moment précis où son raisonnement se fragilisait et à lui donner une méthode pour avancer seul. Les travaux pratiques ont joué un rôle central, car ils l'obligeaient à mobiliser plusieurs notions dans un contexte complet plutôt qu'à les appliquer séparément. Cet accompagnement a contribué à consolider les connaissances nécessaires à l'obtention de son diplôme. De mon côté, il a confirmé qu'expliquer un sujet technique est aussi une forme de contrôle qualité : lorsqu'une notion ne peut pas être formulée simplement, c'est souvent qu'elle n'est pas encore complètement maîtrisée.

Cette expérience a développé une compétence qui m'accompagne depuis : adapter la précision du discours sans dénaturer le fond. Dans un projet, les interlocuteurs n'ont ni le même niveau technique ni les mêmes responsabilités, mais chacun doit pouvoir comprendre les conséquences d'une décision. Le tutorat m'a appris à décomposer un problème, à rendre visibles les étapes de réflexion et à corriger une méthode plutôt qu'un résultat isolé. Cette capacité s'est ensuite retrouvée dans mes échanges avec les utilisateurs, les équipes fonctionnelles, les responsables commerciaux et les responsables de projet. Elle constitue enfin une discipline de vérification : transmettre m'oblige à éprouver mes propres acquis avant de les présenter comme des certitudes.

Avant de rejoindre un projet client, j'ai suivi une formation consacrée au cadre de développement et aux conventions de l'équipe, puis réalisé une application destinée à valider ces acquis. J'ai terminé ce parcours en avance sur le calendrier prévu. Cette progression rapide reposait moins sur une recherche de performance que sur ma manière d'apprendre : comprendre les principes, solliciter les développeurs expérimentés, confronter mes choix à leurs retours et valider cette compréhension par une réalisation concrète.

Dès le premier mois, j'ai pu contribuer à un projet client. La confiance acquise a ensuite élargi progressivement mon périmètre : initialement affecté à un seul sujet, j'ai participé à plusieurs développements, dont certains ont été livrés pendant mon stage. Sur les sujets qui m'étaient confiés, je préparais les points techniques, assurais une grande partie de la réalisation et participais aux échanges nécessaires à leur avancement. Cette autonomie restait accompagnée par mon tuteur et le chef de projet : elle m'a appris que prendre une responsabilité ne consiste pas à travailler seul, mais à savoir quand décider, quand faire valider et sur qui s'appuyer.

Ce projet ne m'a pas seulement appris à développer : il m'a surtout appris à livrer dans un environnement où la sécurité, la traçabilité et la gouvernance conditionnent chaque étape du travail. Une fonctionnalité ne pouvait pas être considérée comme terminée parce qu'elle fonctionnait sur un poste de développement. Elle devait correspondre au besoin formalisé, respecter les conventions, être testée, documentée et soumise aux validations appropriées. J'y ai compris qu'une évolution technique doit pouvoir être expliquée, attribuée et maîtrisée par les personnes qui en portent réellement le risque.

Cette expérience a également structuré ma compréhension de la gestion de projet : séparation des responsabilités, anticipation des dépendances, préparation des livraisons et respect du rythme imposé par la sécurité. Elle a validé ma capacité à évoluer dans un grand compte tout en précisant ce que je recherchais pour la suite. Après avoir appris à produire avec rigueur dans un cadre défini, je souhaitais appliquer cette méthode dans un environnement où je pourrais aussi participer à la conception, à l'architecture et à la vie complète d'un produit. Cette ambition m'a conduit vers l'équipe IBM Smart Green Pallet.

À l'issue de mon projet bancaire, je souhaitais rejoindre un environnement dans lequel je ne serais plus seulement chargé d'implémenter un besoin déjà défini, mais où je pourrais participer à la construction du produit lui-même. J'ai été recommandé en interne auprès de l'équipe IBM Smart Green Pallet, qui fonctionnait comme une équipe produit resserrée au sein d'IBM : il fallait expérimenter, arbitrer, construire et assumer les conséquences des choix réalisés. Chaque ingénieur disposait de son propre périmètre, mais aucun ne pouvait travailler isolément. Le produit ne pouvait fonctionner que si les différentes briques techniques, les contraintes métiers et les opérations de terrain évoluaient ensemble.

IBM Smart Green Pallet associe des palettes plastiques recyclées et recyclables, des capteurs et une plateforme numérique destinée à suivre les flux logistiques et à surveiller la chaîne du froid. Derrière cette description simple se trouvait un enjeu beaucoup plus large : relier des objets physiques, des services informatiques et plusieurs organisations autour d'une information commune, suffisamment fiable pour permettre une décision. La solution devait identifier les équipements, remonter leurs données, détecter des situations anormales et restituer l'information aux équipes concernées. Je passais ainsi d'applications métiers relativement délimitées à un produit distribué, multi-client et destiné à être exploité à grande échelle.

Mes premiers mois ont été consacrés à comprendre le produit avant de prétendre le faire évoluer : son architecture, les échanges entre ses composants, les principes propres aux objets connectés et les méthodes de l'équipe. Les certifications et les premières applications internes m'ont permis de confronter ces acquis à des besoins réels. Je devais montrer que je pouvais partir d'une contrainte opérationnelle, en comprendre les implications et construire une réponse complète, plutôt que traiter isolément une fonctionnalité sans mesurer ses conséquences sur le reste du système.

J'ai ensuite développé les applications utilisées pour observer les données remontées par la solution et vérifier le fonctionnement de ses différents services. Initialement conçues pour accompagner l'expérimentation, elles ont ensuite servi de base au travail mené sur la plateforme web. J'en ai posé puis fait évoluer le cadre applicatif, dans le respect de l'architecture générale définie par l'équipe. Une même plateforme devait servir plusieurs organisations tout en isolant leurs données, leurs utilisateurs et leurs règles : chaque évolution devait donc être pensée comme une capacité durable du produit.