Pourquoi certaines abstractions me passionnent et d'autres m'ennuient immédiatement
Un retour sur mon rapport à la technique et pourquoi certains sujets abstraits me captivent (philosophie, sociologie) tandis que d'autres, purement techniques, ne m'ont jamais vraiment intéressé, même avec l'arrivée de l'IA.
Cet article prolonge la réflexion commencée dans mes deux précédents textes, sur mon rapport au développement et à l'intelligence artificielle.
Depuis quelque temps, j'essaie de comprendre pourquoi j'ai toujours eu autant de mal à m'intéresser profondément à la technique.
Pas à l'utiliser. Pas à apprendre suffisamment pour faire fonctionner quelque chose. Mais à réellement vouloir comprendre ce qui se passe derrière.
Je m'en suis encore rendu compte récemment en préparant une soutenance. Je devais par exemple être préparé à potentiellement expliquer qu'un multi-stage build avec Docker permet de séparer l'étape de compilation avec Maven de l'image finale, qui n'utilise plus que le JRE, notamment pour réduire la taille de l'image et limiter les vulnérabilités potentielles.
Je peux apprendre cette phrase. Je peux même comprendre globalement ce qu'elle veut dire. Mais très rapidement, quelque chose me gêne.
Pourquoi Maven est-il nécessaire pendant la compilation mais pas ensuite ? Qu'est-ce que le JRE contient exactement ? Qu'est-ce qui disparaît réellement de l'image finale ? Pourquoi cela réduit-il sa taille, et surtout, pourquoi cela réduit-il les vulnérabilités ?
Chaque réponse semble ouvrir trois nouvelles portes. Et à ce moment-là, ma réaction est presque toujours la même : d'accord, je vous crois, ça fonctionne, on peut passer à autre chose. Je n'ai ni le temps ni l'envie de creuser le sujet. Ce n'est qu'un exemple parmi des centaines.
Ce n'est pas que je n'aime pas comprendre en général. Je peux passer énormément de temps à essayer de comprendre quelque chose lorsque le sujet m'intéresse : les philosophies, les religions, la sociologie, la psychologie. Je peux lire plusieurs points de vue, comparer des systèmes de pensée, essayer de comprendre pourquoi des individus ou des sociétés fonctionnent d'une certaine manière, et continuer à creuser simplement parce que chaque réponse crée une nouvelle question intéressante.
Dans ces domaines, l'abstraction ne me dérange pas. Au contraire. Je peux trouver passionnante une idée qui n'a aucune application pratique immédiate.
Ce rapport ne date d'ailleurs pas de l'informatique. Je me souviens avoir ressenti exactement la même chose au lycée, avec les mathématiques et la physique. Quand on m'expliquait pourquoi la lumière blanche pouvait se décomposer en différentes couleurs, ma réaction n'était pas : c'est fascinant, je veux comprendre ce phénomène jusqu'au bout. C'était plutôt : d'accord, et donc ?
Je pouvais parfaitement accepter qu'un phénomène existe sans ressentir le besoin d'explorer toute la physique qui se cachait derrière. À l'inverse, je pourrais passer des heures à discuter de pourquoi deux sociétés développent des normes morales différentes, ou pourquoi deux personnes interprètent le même événement de manière complètement opposée, ou imaginer des scénarios alternatifs si tel chef de guerre avait fait tel choix plutôt que tel autre à tel moment de l'histoire.
Ce n'est donc pas vraiment la complexité qui me rebute. C'est la nature de la complexité.
J'ai longtemps mal formulé le problème en me disant que j'étais simplement mauvais avec les choses abstraites. Pourtant une religion est abstraite. Une idéologie l'est aussi. Et pourtant, je peux passer des heures à essayer de les comprendre.
La différence est ailleurs. Quand je creuse une idée en psychologie, en sociologie, en philosophie ou dans une religion, l'abstraction finit presque toujours par me ramener à des êtres humains : pourquoi quelqu'un croit-il cela, pourquoi agit-il ainsi, pourquoi une société considère-t-elle un comportement comme normal et une autre non. Même très abstrait, le concept débouche quelque part, il m'aide à comprendre des comportements, des intentions, des valeurs, des conflits ou des sociétés réelles.
Avec la plupart des concepts techniques, je ressens quelque chose de très différent. Pourquoi faut-il mettre les couches Docker les plus stables avant les plus volatiles ? Parce que cela permet de mieux utiliser le cache. Pourquoi ? Parce que Docker peut réutiliser certaines couches tant qu'elles n'ont pas été invalidées. Et ainsi de suite. Chaque réponse me fait descendre un peu plus profondément dans le fonctionnement du système, mais au bout de cette descente, il y a encore le système. Je ne découvre rien sur les humains, leurs comportements ou leurs croyances. Je comprends simplement un peu mieux comment fonctionne Docker ou tel langage ou tel framework. Pour certaines personnes, c'est visiblement passionnant, mais ça ne l'a jamais été pour moi.
Et cela explique probablement beaucoup de choses : pourquoi j'ai toujours su développer sans jamais tomber amoureux du code ; pourquoi je peux m'approprier un outil juste assez pour bâtir ce dont j'ai besoin, sans chercher à explorer les couches inférieures ; pourquoi les bonnes pratiques restent chez moi des règles appliquées plutôt que des intuitions viscérales. Et pourquoi, après plusieurs années d'expérience, je ne suis toujours pas devenu ce développeur habité par l'envie de disséquer chaque système jusqu'à l'atome.
Au fond, il ne s'agit pas de juger si cette approche est bonne ou mauvaise, même si, pour les puristes, elle reste sans doute discutable.
Au fond l'intelligence artificielle n'a rien inventé dans mon rapport à la technique : elle n'a fait qu'accélérer une démarche déjà bien ancrée. Bien avant les LLM, je concevais des applications fonctionnelles en assemblant de la documentation, des tutoriels et des briques logicielles pour arriver au résultat voulu, sans chercher à percer les mystères sous le capot. Les frameworks m'y avaient préparé en apportant leur part d'abstraction et de conventions prêtes à l'emploi.
Avec l'IA, cette distance s'est simplement démultipliée. Aujourd'hui, je peux formaliser un besoin, laisser un agent proposer et implémenter la solution, valider le résultat et avancer sans maîtriser chaque rouage interne. L'approche comporte évidemment des risques : c'est pour cela que je croise les agents et les modèles, notamment en revue de code, pour détecter les angles morts du premier jet, ce qui arrive régulièrement. Mais pour l'instant, le constat est là : cette méthode fonctionne. Je n'ai pas besoin de tout décortiquer pour livrer.
Et si mon rôle consistait finalement davantage à concevoir, orchestrer et livrer qu'à disséquer l'infrastructure invisible des systèmes, est-ce réellement un problème ?