Dix ans avant que le métier ait un nom
De la mécanique des sols aux entrepôts de données, un journal de lecture tenu depuis 2011 raconte une décennie où la discipline s’est nommée après coup. Ce qu’il montre, et ce qu’il cache.
Je tiens depuis 2011 un journal de lecture : ce que j’ai lu, dans quel mois, et pourquoi cela me servait alors. Il n’a jamais été écrit pour être relu d’un bout à l’autre, et c’est ce qui le rend utile aujourd’hui : il n’a pas été arrangé après coup. Relu d’une traite, il raconte une chose que je n’aurais pas su dire sur le moment : pendant la première moitié de cette décennie, le métier que j’allais exercer n’avait pas encore de nom stable.
Les premières entrées ne parlent pas d’informatique mais de calcul. Un aide-mémoire de mécanique des sols voisine avec un traité de C++ et des scripts d’une ligne pour éditer du texte. Je venais d’une formation d’ingénieur mécanicien, et l’ordinateur y était un instrument de calcul, pas un sujet. Je notais alors surtout des formulaires : des feuilles denses qu’on imprime et qu’on garde sous la main. C’est une habitude d’école d’ingénieur, et elle a mis dix ans à s’effacer.
En 2012, trois textes de presse économique annoncent la même chose : que les données deviennent une matière première, et que quelqu’un devra s’en occuper. Le journal indique explicitement qu’ils m’ont fait changer d’orientation. Avec le recul, ce qui frappe n’est pas leur justesse, elle était partielle, mais leur effet : ils ont donné un nom à un travail que des gens faisaient déjà sans lui. C’est le mécanisme habituel, et il vaut d’être regardé en face.
« J’ai donc trouvé que programmation dynamique était un bon nom. C’était une chose à laquelle même un membre du Congrès ne pouvait pas s’opposer. Je m’en suis servi comme d’un parapluie pour mes activités. »
Bellman parle de 1950 et de recherche opérationnelle, mais il décrit exactement ce qui s’est passé pour la donnée soixante ans plus tard. Le nom n’a pas décrit le travail : il l’a rendu finançable. Savoir cela ne dispense pas d’exercer le métier ; cela dispense seulement de croire que le mot désigne quelque chose de neuf.
- Harvard Business Review · Data Scientist: The Sexiest Job of the 21st Century (2012)
- Harvard Business Review · Big Data: The Management Revolution (2012)
De 2013 à 2015, le journal est occupé par des problèmes qui ont presque disparu du discours : produire des documents bureautiques depuis du balisage, manipuler du texte enrichi, tracer des graphiques sans code exécuté par le navigateur, reprendre du code hérité écrit dans des langages qui n’avaient déjà plus de relève. Un calculateur en ligne y figure comme la première expérience marquante d’un calcul lourd exécuté ailleurs que sur ma machine. C’est là, sans que je l’aie remarqué, que commence la partie cloud de l’histoire.
À partir de 2016, le sujet change de nature. Le contrôle de version cesse d’être un outil pour devenir une manière de travailler à plusieurs. Puis viennent les langages fonctionnels et le calcul réparti, avec tout ce que cela suppose de mémoire à surveiller et de tâches à soumettre. La bascule est nette : la difficulté n’est plus d’écrire le calcul, elle est de le faire tenir sur des machines qu’on ne voit pas.
Entre 2017 et 2019, le journal se remplit de statistique et d’apprentissage : cours magistraux, ouvrages de référence, notebooks. C’est le moment où la science des données occupe toute la conversation. Mais ce que je notais en parallèle (servir un modèle, l’exécuter en production, tenir une chaîne qui alimente ces expériences) n’avait pas encore de nom et n’intéressait personne. Le métier d’ingénieur de la donnée s’est constitué là, en creux, comme la somme des problèmes que la partie prestigieuse laissait derrière elle.
Un changement traverse toute la décennie sans jamais être annoncé. En 2011, ma source principale était la documentation de l’éditeur. À la fin, c’est le dépôt public : on lit le code avant la notice, on regarde les tickets ouverts avant la page de présentation, et l’on juge un outil à la vivacité de ses échanges plutôt qu’à la qualité de sa page d’accueil. GitHub n’a pas seulement hébergé du code, il a déplacé l’endroit où l’on apprend. Cela a un revers, qu’il faut nommer : on y lit surtout ce qui est visible, donc ce qui est populaire.
Il ne consigne que ce que j’ai lu, et une lecture n’est pas une compétence. Il ne dit rien des mois passés sur un problème sans rien noter, ni des outils que j’ai abandonnés parce qu’ils ne fonctionnaient pas. Il exagère donc la cohérence : lu à la suite, il donne l’impression d’une trajectoire, alors qu’il enregistre surtout ce qui était disponible au moment où j’ai cherché. Je le publie comme document daté, non comme conseil de parcours, et sûrement pas comme itinéraire à refaire, puisque la moitié de ce qu’il cite n’existe plus.