L'informatique est faite pour automatiser

“La civilisation progresse en augmentant le nombre d’opérations importantes que nous pouvons accomplir sans y penser.”

Ces mots sont d’Alfred North Whitehead, philosophe et mathématicien britannique du XIXe siècle. Il ne parlait pas d’IA. Il parlait de l’écriture, du calcul symbolique, de la roue. Pourtant, en 2026, cette phrase décrit avec une précision troublante ce que l’IA générative est en train de faire au développement logiciel. Ce n’est pas une révolution. C’est une continuité.

En 2003, je commençais des études en informatique industrielle pour obtenir mon diplôme de technicien. J’étais tombé dans ce cursus après avoir testé une bonne partie des options disponibles dans mon établissement. Je fais partie des gens qui se sont beaucoup ennuyés lors de leur scolarité. Heureusement, au même moment, le jeu en ligne et les LAN faisaient leur apparition. J’avais donc décidé, sur un coup de tête, de faire de l’informatique parce que j’aimais rester devant un ordinateur.

S’ensuivit une année en école supérieure d’informatique, toujours dans le milieu industriel. C’est là que notre professeur d’algorithmie prononça la phrase qui résonne encore aujourd’hui : l’informatique est faite pour automatiser. Ce n’était pas un conseil de carrière. C’était une définition du métier. Depuis, je tente au maximum de suivre ce mantra, et l’IA générative ne m’en a pas fait dévier. Elle l’a confirmé.

Whitehead et la hiérarchie de l’attention

Whitehead ne plaidait pas pour la paresse intellectuelle. Il défendait quelque chose de plus subtil : le progrès consiste à rendre automatiques les opérations maîtrisées, pour libérer l’esprit vers ce qui est encore non résolu.

Sa métaphore militaire reste frappante : “Les opérations de la pensée sont comme des charges de cavalerie dans une bataille : leur nombre est strictement limité, elles nécessitent des chevaux frais et ne doivent être entreprises qu’à des moments décisifs.”

L’attention est une ressource rare. Chaque décision que tu peux confier à une routine, un outil ou un système, c’est un cheval frais que tu gardes pour la vraie bataille. Ce principe n’a pas attendu l’IA pour s’appliquer au développement logiciel. Il l’a structuré depuis le début.

Une continuité, pas une rupture

Chaque génération de développeurs a vécu sa propre révolution supposée. L’assembleur remplacé par le C. Le C supplanté par les langages de haut niveau. Les frameworks qui ont aboli le besoin de réinventer l’accès aux bases de données ou la gestion des routes HTTP. Les pipelines CI/CD qui ont rendu le déploiement invisible.

A chaque étape, le même schéma : une couche d’abstraction supplémentaire rend automatique ce qui exigeait auparavant une attention soutenue. Et à chaque étape, les mêmes craintes : les développeurs vont perdre leurs compétences, le métier va se vider de sa substance.

Ce ne fut jamais le cas. Chaque couche supplémentaire a simplement déplacé la frontière de ce qui mérite de l’attention. Le développeur qui maîtrisait la gestion manuelle de la mémoire n’a pas disparu : il a pu se concentrer sur la logique métier, l’architecture, l’expérience utilisateur.

L’IA générative suit exactement cette trajectoire. Ecrire un test unitaire à partir d’une fonction existante, générer un premier jet de documentation, proposer une implémentation depuis une spécification en langage naturel : ces tâches ne disparaissent pas. Elles descendent d’un niveau dans la hiérarchie de l’attention.

Ce que j’ai appris en déléguant en aveugle

Ce serait trop simple de conclure que chaque couche d’abstraction est un cadeau sans contrepartie.

J’en ai fait l’expérience en développant la fonctionnalité de recherche de ce blog. Le principe semblait simple : vectoriser les articles, stocker les embeddings, interroger la base pour retourner les contenus les plus proches d’une requête. L’IA m’a aidé à mettre en place le pipeline rapidement. Le code tournait. Les résultats remontaient.

Sauf qu’ils étaient mauvais. Une recherche sur “déploiement continu” remontait un article sur l’écoconception. Une requête sur “monorepo” renvoyait un texte sur les contrats de données. Techniquement, tout fonctionnait. Sémantiquement, rien ne tenait.

La cause était simple, et embarrassante : les embeddings étaient calculés uniquement sur les tags des articles, pas sur leur contenu. Deux articles partageant les tags “IA” et “développement” se retrouvaient voisins dans l’espace vectoriel, peu importe leur sujet réel. Je n’avais pas spécifié ce qui devait être vectorisé. L’IA avait pris la valeur la plus courte et la plus propre disponible dans le schéma. Un choix défendable sur le papier, catastrophique en pratique. C’est moi qui n’avais pas formulé la contrainte.

Automatiser sans comprendre ce qu’on automatise, c’est construire sur du sable. Un développeur qui valide du code généré sans en saisir les implications ne gagne pas du temps. Il accumule une dette cognitive qu’il paiera avec des intérêts. La distinction est importante : déléguer une tâche maîtrisée libère de l’énergie. Déléguer une tâche mal comprise transfère un risque.

C’est précisément là que la continuité historique a une exigence : chaque nouvelle couche d’abstraction suppose que les couches inférieures ont été comprises avant d’être abandonnées. Le développeur qui n’a jamais écrit un test à la main aura du mal à évaluer si le test généré couvre vraiment les cas qui comptent.

Ce qui ne change pas

Ce que l’IA générative ne remplace pas, c’est le jugement. Savoir quoi automatiser. Reconnaître quand une réponse générée est techniquement correcte mais conceptuellement fausse. Décider à quel niveau d’abstraction travailler selon le contexte.

Ces compétences ne sont pas des résidus de l’ère pré-IA. Elles sont ce que Whitehead appelait les “moments décisifs”. La frontière de l’automatisation recule vite. Ce qui ne recule pas, c’est la nécessité de comprendre ce qu’on confie à la machine avant de le lui confier.

Mon professeur d’algorithmie avait raison : l’informatique est faite pour automatiser. Ce qu’il ne pouvait pas anticiper, c’est que l’outil d’automatisation suivant serait capable de générer du code à partir d’une phrase. Mais le mantra, lui, tient toujours. Et il tient pour la même raison qu’en 2003 : automatiser intelligemment, c’est choisir où dépenser ses chevaux frais.