Déjà-vu : une réflexion sur l’ingénierie et la compétence à l’ère de l’IA

Introduction

Vous savez implémenter QuickSort ? Bubble Sort ? Merge Sort ? Très bien. Maintenant, une question plus intéressante : à quand remonte la dernière fois où vous en avez réellement implémenté un ? Probablement à assez longtemps. Et pourtant, je parie que vous avez trié des données un nombre incalculable de fois depuis, que ce soit avec sort(), un ORDER BY en SQL, la fonction de tri d’Excel ou l’une des innombrables bibliothèques qui abstraient ce problème. Avez-vous pour autant cessé de comprendre les algorithmes de tri ? Bien sûr que non. Vous avez simplement cessé de les implémenter à la main parce qu’une meilleure abstraction est devenue disponible. En informatique, cela arrive tout le temps. Si vous avez étudié l’architecture des ordinateurs, vous avez probablement implémenté des circuits combinatoires (ah, PCS2355, quel souvenir… ou pas !), construit des additionneurs, écrit des programmes en assembleur ou dû vous préoccuper de la gestion manuelle de la mémoire. Aujourd’hui, la plupart d’entre nous travaillent avec des langages de haut niveau, utilisent des bibliothèques écrites par d’autres, exécutent des applications dans des conteneurs et consomment des services cloud sans vraiment penser au nombre impressionnant de couches qui se trouvent en dessous. Chacune de ces couches a rencontré de la résistance. Il y a toujours eu des gens pour confondre nouvelle abstraction et perte de compétence. Comme si ne plus manipuler directement des registres signifiait moins comprendre l’informatique. Comme si programmer en Python était en quelque sorte « moins de l’ingénierie » que programmer en C. Peut-être que toute abstraction majeure est d’abord perçue comme une perte avant d’être reconnue comme un progrès. Ces derniers temps, j’ai une forte impression de déjà-vu. Je me souviens avoir défendu Python face à des collègues qui soutenaient presque que C était le seul langage de programmation « sérieux ». C était plus rapide, permettait de contrôler la mémoire, produisait des programmes plus efficaces et gardait le programmeur au plus près de la machine. Python, en revanche, était interprété, dynamiquement typé (quel sacrilège !), lent, et masquait des détails que beaucoup considéraient comme des connaissances indispensables à tout bon programmeur. Le résultat inévitable, selon cet argument, serait l’apparition de générations de professionnels comprenant de moins en moins bien l’informatique. Je n’ai jamais vu les choses de cette façon. Mon argument était pratique, pas dogmatique. Quand j’implémentais des algorithmes cryptographiques et que nous cherchions à gagner quelques millisecondes, C — avec des routines écrites en assembleur ! — était le bon outil. Dans d’autres situations, Python permettait d’abstraire une quantité énorme de détails qui n’apportaient tout simplement pas beaucoup de valeur au problème que j’essayais de résoudre. Je pouvais ainsi consacrer beaucoup plus de temps au domaine applicatif et beaucoup moins à la mécanique de l’implémentation. Aujourd’hui, j’ai l’impression que nous avons presque exactement le même débat. Il existe une citation attribuée à David Wheeler que j’aime particulièrement :

« Any problem in computer science can be solved by another level of indirection. »

Je pense qu’il avait tout à fait raison. Mais aujourd’hui, j’en ajouterais une autre :

Toute abstraction qui réussit change ce que signifie être compétent.

L’IA comme prochaine abstraction

Jusqu’à présent, les grandes abstractions de l’informatique concernaient principalement la machine. L’IA représente une étape différente. Pour la première fois, nous commençons à abstraire une partie du travail cognitif impliqué dans l’ingénierie logicielle et, plus largement, dans l’informatique elle-même. L’IA peut désormais écrire du code, produire de la documentation, proposer des architectures, générer des tests, traduire d’un langage à un autre, expliquer des API, résumer des articles, construire des requêtes, relire des pull requests et nous aider dans bien d’autres tâches. Ce qui m’intéresse n’est pas tant la qualité de chaque résultat pris individuellement. C’est le fait que nous pouvons désormais automatiser de manière réellement utile des activités qui, jusqu’à récemment, dépendaient presque entièrement du travail intellectuel de spécialistes. En tout cas, je ne travaille plus de la même manière. Aujourd’hui, j’écris moins de code, mais je produis davantage. Le temps que je consacrais auparavant à l’implémentation est désormais passé à décider quoi implémenter, pourquoi l’implémenter et, surtout, quelle est la meilleure manière de le faire. L’implémentation reste importante. Mais ce n’est plus le principal goulot d’étranglement. La partie la plus difficile consiste désormais à bien comprendre le problème, à décomposer des systèmes complexes, à prendre des décisions d’architecture, à intégrer différentes technologies et à évaluer de manière critique ce que produit l’IA.

La même histoire en cybersécurité

Si vous travaillez dans la sécurité, vous avez probablement déjà assisté à une évolution similaire. Pendant de nombreuses années, une grande partie du renseignement sur les menaces était distribuée sous forme d’IoC : hashes, adresses IP, domaines et URL. David Bianco a parfaitement résumé les limites de cette approche avec la Pyramide de la douleur. Le progrès n’a pas consisté à abandonner les IoC. Il a consisté à comprendre qu’ils n’étaient que les représentations de quelque chose de plus profond. À mesure que nous remontons la pyramide vers les TTP, nous passons moins de temps à poursuivre des artefacts individuels et davantage à modéliser le comportement de l’adversaire. Nous sommes montés d’un niveau d’abstraction. Et, ce faisant, nous avons amélioré notre capacité à construire des défenses plus robustes. Peut-être sommes-nous en train de vivre la même transition dans l’informatique. Le code est une représentation. Une requête KQL est une représentation. Une règle Sigma est une représentation. Un IoC est une représentation. Même un prompt est une représentation ! Pendant longtemps, savoir produire correctement ces représentations était un assez bon indicateur de compétence. L’IA affaiblit ce lien. Elle peut produire de très bonnes représentations. Mais cela ne signifie pas qu’elle comprend le problème que ces représentations sont censées résoudre. Ce qui compte de plus en plus, c’est de maîtriser ce qui se trouve derrière : comprendre le problème, formuler de bonnes hypothèses, concevoir des solutions, identifier les limites, évaluer les trade-offs et exercer son jugement technique. Autrement dit :

La connaissance n’a pas perdu de sa valeur. Elle s’est simplement déplacée.

Méthode

Si vous êtes d’accord avec le raisonnement jusqu’ici, la réponse serait-elle simplement d’« utiliser l’IA » ? Ce serait à peu près aussi utile que de dire à quelqu’un d’« écrire un programme » pour résoudre son problème. La différence n’a jamais été dans l’outil. Elle a toujours été dans la méthode. « Travailler avec l’IA » n’est pas une compétence en soi. C’est une discipline. Cela signifie apprendre à décomposer les problèmes, à fournir le bon contexte, à valider les réponses, à comprendre les limites, à intégrer les outils et à construire des processus fiables et reproductibles. J’ai beaucoup appris en suivant Matt Pocock. Une de ses observations m’a particulièrement marqué : l’IA déplace notre travail vers la réflexion stratégique. Plus j’observe ma propre façon de travailler au quotidien, plus je suis d’accord. Je passe moins de temps à produire des artefacts techniques et davantage à réfléchir à la manière dont ces artefacts devraient être produits.

Conclusion

J’ai vu des collègues considérer les « travaux produits avec [l’aide de] l’IA » comme s’ils étaient, par définition, inférieurs. Je ne vois pas les choses ainsi. Une grande partie de l’histoire de l’informatique est celle de personnes qui ont appris à créer davantage de valeur en travaillant à des niveaux d’abstraction toujours plus élevés. Les compilateurs n’ont pas diminué la valeur de ceux qui savaient programmer en assembleur. Les langages de haut niveau n’ont pas diminué la valeur de ceux qui savaient programmer en C. Les frameworks n’ont pas diminué la valeur de ceux qui comprenaient les protocoles. L’IA nous apporte simplement un nouveau niveau d’abstraction. Et, comme cela s’est déjà produit à de nombreuses reprises, cela change aussi ce que signifie être compétent. Nous aurons toujours besoin d’une compréhension profonde des fondamentaux de l’informatique. Peut-être même plus que jamais. La différence est que cette connaissance s’exprimera de moins en moins par notre capacité à produire nous-mêmes des représentations, et de plus en plus par notre capacité à formuler des problèmes, concevoir des solutions, guider des systèmes intelligents et exercer notre jugement technique. L’IA ne rend pas l’ingénierie moins importante. Elle la rend plus importante. Car lorsque l’exécution cesse d’être le principal facteur limitant, ce qui distingue réellement un excellent professionnel devient beaucoup plus visible. L’histoire de l’informatique n’est pas celle d’une production toujours plus importante de code. C’est l’histoire d’un besoin toujours moindre d’en écrire pour résoudre des problèmes toujours plus grands. Le défi n’est pas de décider si nous allons « utiliser l’IA ». C’est d’apprendre à réellement travailler avec elle.