À propos
Thomas Dimnet
Mon tout premier poste de développeur, un collègue m'a demandé d'implémenter une factory. Je ne savais pas ce que c'était.
Je suis allé le voir pour qu'il m'explique. Et en creusant avec lui, je me suis rendu compte d'une chose : lui non plus ne savait pas vraiment. Il connaissait le pattern, il s'en servait tous les jours — mais le dire avec des mots simples, il n'y arrivait pas.
Ça m'a marqué plus que ça n'aurait dû. Être bon techniquement et savoir l'expliquer, ce sont deux choses différentes — et la première ne donne pas la seconde. J'allais recroiser ce mur souvent : des gens brillants, incapables de transmettre ce qu'ils savaient.
C'est sans doute là que les deux fils de mon parcours ont commencé à se tendre en même temps. Construire des systèmes. Apprendre aux gens à les construire. Pendant treize ans, je n'ai jamais lâché ni l'un ni l'autre — et chaque fois qu'on m'a demandé de choisir, j'ai dit non.
Pendant toutes ces années où je développais, je n'ai jamais cessé d'enseigner. Le soir, les week-ends, à côté de chaque poste.
Ça a commencé par du mentorat, une heure par semaine avec un apprenant que j'aidais à débloquer son projet. Puis j'ai évalué des soutenances, animé des sessions, écrit des cours. Quatre ans chez OpenClassrooms, en parallèle de mon travail de développeur, sans que jamais l'un prenne la place de l'autre.
Ce qui me tenait là, c'était ce mur croisé à mon premier poste et recroisé partout ensuite — jusque chez les spécialistes de l'infra et des bases de données : des gens qui savaient faire, mais pas transmettre. Plus je pratiquais, plus je voyais ces deux mondes vivre séparés, et personne pour s'occuper du pont entre eux.
Alors le jour où OpenClassrooms m'a proposé un poste d'enseignant à plein temps — arrêter de développer pour ne faire que ça — j'ai dit non. Pas par prudence. Parce que retirer la pratique, c'était retirer ce qui rendait mon enseignement vrai. Ces deux voies n'ont jamais été deux métiers menés de front. C'était le même métier, vu des deux côtés.
À la même époque, je suis devenu CTO. Et c'est là, loin de toute salle de cours, que je me suis surpris à faire exactement le même geste.
Il fallait conteneuriser notre infrastructure. Le choix par défaut, celui qu'on attend d'un CTO, c'était Kubernetes — l'outil le plus puissant, le plus impressionnant sur un CV. J'ai pris Docker Swarm. Moins prestigieux, beaucoup plus simple. Parce que je ne cherchais pas l'outil qui me ferait bien voir : je cherchais celui que toute l'équipe pourrait comprendre, faire tourner, et réparer un dimanche soir sans moi.
J'aurais pu imposer Kubernetes pour la photo. Choisir Swarm, c'était préférer ce que l'équipe pouvait vraiment porter à ce qui m'aurait flatté.
Je refais ce geste aujourd'hui, sur NX. Le site tient au maximum sur Astro, sans API, sans base de données — pas parce que je ne sais pas en construire, j'en ai fait des dizaines, mais parce que chaque brique qu'on ajoute est une brique qu'il faudra comprendre et maintenir. Retirer, ici, n'est pas une limite. C'est une décision.
Et c'est exactement l'acte que je pose en préparant un cours : garder ce qui compte, écarter le reste. Sauf qu'ici, il n'y a pas d'élève. Juste du code. Ce geste ne vient pas de ma façon d'enseigner — ma façon d'enseigner en est une conséquence.
Quelques années plus tard, je suis pourtant devenu professeur à plein temps — dans une école qui formait des adolescents à la programmation. La différence avec le poste que j'avais refusé, c'est que cette fois je n'arrêtais pas de coder : NX tournait en parallèle. Et, le plus étrange, je n'avais jamais autant développé que depuis que je m'étais lancé dans ce projet d'enseignement.
On ne m'avait pas seulement recruté pour donner des cours, mais pour refondre un programme qui n'avait pas de vraie progression — ni sur l'année, ni sur les trois. J'ai passé la première année à le reconstruire de zéro : décider quoi enseigner, dans quel ordre, et quoi laisser dehors. L'année suivante, avec cette progression en place, ça a tenu.
C'est là aussi qu'on m'a appris à enseigner. Ma directrice venait de l'Éducation nationale, formée aux sciences cognitives et aux sciences de l'éducation. Jusque-là, j'enseignais d'instinct ; elle m'a fait travailler ce qui ne s'improvise pas — la posture devant une salle, le rythme d'une séance, ce qu'on fait d'un silence. C'est ce métier, appris sur le terrain, que je fais aujourd'hui valider par une VAE.
Depuis un an, chez Scaleway, les deux voies ne font plus qu'un seul poste. On m'a recruté pour monter un programme de formation : transmettre l'ingénierie pédagogique à des ingénieurs qui savent construire mais pas encore enseigner, et leur donner l'exemple en concevant moi-même les formations, des plus simples aux plus techniques. Je forme, et je forme ceux qui formeront.
Ce que je mesure surtout, c'est à quel point ce profil est rare. Parce que je n'ai jamais cessé de pratiquer, je peux m'asseoir avec des ingénieurs et les faire monter, puis reprendre la même idée pour quelqu'un qui débarque — sans devenir quelqu'un d'autre entre les deux. Les deux voies que je refusais de départager n'en font plus qu'une.
Aujourd'hui, quand on me demande ce que je fais, je n'ai plus de réponse courte. Développeur ? Enseignant ? Les deux mots sont vrais, aucun ne suffit seul.
Je continue d'explorer, d'ailleurs — ces temps-ci du côté du game design, un premier jam, une ville que je construis brique par brique. Et je retombe sur la même évidence qu'ailleurs : un bon jeu ne naît pas de ce qu'on y empile, mais des quelques éléments qu'on choisit pour ouvrir le plus de profondeur. Toujours le même geste, sur un terrain de plus.
Tout est parti d'un développeur à son premier poste qui ne savait pas ce qu'était une factory — et qui a compris, ce jour-là, que savoir et savoir transmettre sont deux choses différentes. J'ai passé les treize années suivantes sur le pont entre les deux. Je n'en suis jamais redescendu.
NX Academy