Rester en mouvement dans un monde instable : l'agentivité comme levier

Bonjour à tous, j’espère que vous allez bien. C’est très plaisant de vous voir aussi nombreux. Vous continuez quand même à rentrer, donc c’est trop cool.

Vous vous entassez un petit peu dans le fond. Vous l’avez vu sur le programme, on était censés être deux. Malheureusement, je serai tout seul : Julia n’a pas pu se joindre à nous aujourd’hui, donc je vais essayer d’assurer ça tout seul.

Ce n’était pas prévu, mais ce n’est pas très grave. J’aimerais peut-être qu’on fasse ça sous un format un peu différent de ce qui était prévu.

Vous allez le voir, ça peut être assez vite anxiogène, ça peut potentiellement vous faire poser beaucoup de questions. Et comme on est nombreux, qu’on vient tous d’entreprises différentes et qu’on a des pratiques différentes, ça peut aussi être l’occasion de partager et d’échanger.

Donc si, à tout moment, vous avez des questions, des retours d’expérience, des choses que vous faites par rapport à ce que vous voyez et à ce qui est dit, n’hésitez pas à le faire circuler. Je pense que tout le monde serait hyper content de savoir ce qui se passe aussi ailleurs, dans les autres entreprises.

Et je m’occuperai de faire le relais des questions et des infos pour que tout le monde puisse entendre.

Pour bien commencer cette conférence, il faut qu’on prenne un petit temps pour comprendre d’où elle vient, pourquoi on l’a écrite et quelle est son origine. Pour ça, je vais vous raconter une petite histoire.

Il y a dix ans, j’étais au lycée. Et en fait, le lycée, c’est le moment où on est à Parcoursup, où on choisit la possibilité de choisir son avenir, de choisir ce qu’on va faire plus tard en postulant à des écoles.

C’est un moment où, vraiment, on a le choix de devenir ce qu’on veut. On peut devenir professeur, musicien, docteur, acteur, vétérinaire, artiste, policier, écrivain, même ingénieur ou même astronaute, en vrai. On a la possibilité de rêver en grand.

On se dit : voilà, dans 10 ans, c’est ça, potentiellement, que je vais faire. Une fois qu’on a fait son choix, pour mon cas c’était des études d’ingénieur, on rentre dans une école en post-bac, on continue à se former pendant cinq ans, on passe beaucoup de temps à travailler et à apprendre des choses.

Pour, à la fin, espérer décrocher un diplôme et pouvoir rentrer dans le monde du travail. Sur le papier, c’est relativement simple : ça commence donc au lycée, on s’imagine des choses, on travaille pour les avoir et, à la fin, on a le diplôme et on fait ce qu’on avait envie de faire.

Sur le papier, c’est simple. Et puis, dans la réalité, en 2024, on arrive sur le monde du travail, et qu’est-ce qu’on voit ? On voit que l’IA va remplacer les développeurs, c’est con quand on a fait une école d’ingé pour devenir développeur, que les emplois intellectuels sont condamnés et que les juniors n’ont plus d’avenir.

C’est vraiment dommage quand on arrive sur le monde du travail à ce moment-là. On a comme ça des articles qui titrent beaucoup trop de choses, des fois, et qui nous disent que finalement tout ce pour quoi on s’était préparés, tout ce qu’on avait imaginé depuis dix ans, c’était mort.

Ça n’arriverait pas, et tout le métier qu’on s’était dit qu’on allait vouloir faire et pouvoir faire, en fait, on s’était potentiellement formés pour rien. Et là, ça fait un peu mal.

On s’est rendu compte qu’on n’était pas du tout tout seuls dans ce cas-là. Il y avait beaucoup de gens : évidemment des gens qui finissaient leurs études à ce moment-là, mais aussi toutes les personnes qui pouvaient être en reconversion.

On a donc fait face à un choix, à un dilemme. On s’est demandé quelles étaient nos deux possibilités face à ça.

Soit on reste dans la peur, dans le sensationnalisme, dans tout ce que la presse a essayé de nous vendre pendant quelques années, à se dire que finalement on n’a pas d’avenir, qu’on est fichus et qu’on est bons à rien. Soit on essaye d’aller un petit peu plus loin.

Et on essaye de se questionner, de comprendre quelle est la réalité, ce qui se passe et comment, justement, on peut agir sur soi, sur son environnement, pour pouvoir continuer à exister là-dedans et ne pas se faire écraser par tout ce qu’on pouvait lire.

Pour ajouter un peu de contexte à tout ça, en écrivant la conférence et en préparant le sujet, j’ai essayé de m’immerger à fond dans le truc, vraiment jusqu’au bout. Concrètement, ça veut dire que depuis novembre, à peu près, sur mes projets persos, je n’écris quasiment plus de code.

Tout est délégué à des agents, pour voir jusqu’à quel point, effectivement, on peut se faire remplacer. Globalement, ça se passe comment ? Je travaille beaucoup avec Copilot, via mon téléphone entre autres, ou mon ordi.

Je lance des agents sur le cloud, sur GitHub, Copilot Agent, ils font les trucs pour moi. Je prends le métro, hop, je lance un petit agent, je rentre chez moi le soir, je fais une review, et globalement ça part en prod.

Au travail, c’est un peu différent. J’ai un petit secret en ce moment : mon objectif, c’est de ne plus écrire de code.

Donc c’est trouver des astuces, des manières de faire en sorte de ne plus avoir à écrire de code. Est-ce que c’est une bonne idée ? Je ne sais pas. Mais au moins, ça m’oblige à m’immerger dans le truc à fond.

Et là, c’est peut-être encore moins une bonne idée, l’avenir nous le dira, mais j’utilise ChatGPT à tout-va, notamment en lui parlant comme si c’était un humain. Et je regarde ce qu’il me répond.

J’ai donc essayé de pousser le curseur à fond, de tester un petit peu les limites, pour pouvoir aujourd’hui vous en faire quelque chose de le plus intéressant possible.

Avant de rentrer sur des éléments plus concrets, il y a deux choses dont j’aimerais qu’on parle, entre autres : les benchmarks. Le premier, c’est ARC-AGI 2. Il y a le 3 qui est sorti récemment.

Vous avez en abscisse un prix logarithmique, donc vous avez à la fin 100, je crois, 10 avant et 1. Et vous avez sur la partie ordonnée le score.

Globalement, les chiffres n’ont pas beaucoup d’importance en soi. Ce qu’il faut juste savoir, c’est qu’au maximum, sur les abscisses, on est à $100.

Ce qu’on voit, c’est une augmentation de la performance des modèles. Vous ne voyez pas les noms, mais ici on est sur les derniers modèles les plus performants, et là on est sur les premiers modèles.

Plus ça va, plus la tendance vise à faire une exponentielle, et donc une augmentation de la performance des modèles, sans pour autant une grosse augmentation du prix. Autrement dit, faire travailler une IA, c’est moins cher que de vous faire travailler, vous, dépendant de ce qu’on leur fait faire. Mais c’est ça, un peu, l’idée.

L’autre benchmark met des années en abscisse et une durée de tâche en ordonnée. L’idée, c’est de voir que la progression est exponentielle en fonction de la longueur de tâche avec un certain niveau de fiabilité.

En gros, il faut lire le fait qu’aujourd’hui on a des IA qui sont capables de réaliser des tâches de 6 heures avec une capacité de résolution à 50 %. L’IA ne va pas travailler 6 heures, mais c’est un équivalent de vous qui travailleriez 6 heures.

La partie intéressante, encore une fois, ce ne sont pas les chiffres, c’est de voir que c’est exponentiel. Et que, globalement, on est au début d’un changement qui ne fait que croître de manière exponentielle.

Donc ce que je vous dis là ne sera peut-être plus valable demain. Et enfin, il y a un autre article qui est intéressant. Là, ce n’est pas un benchmark, c’est Situational Awareness, qui a été écrit par un ancien d’OpenAI.

Il fait une centaine de pages, il est très intéressant, je vous conseille d’aller le lire, mais globalement il nous parle aussi de la manière dont les choses vont évoluer. Ce qu’il explique, c’est que l’augmentation de la puissance de calcul, l’amélioration algorithmique, que ce soit au niveau software ou au niveau hardware, ou même l’outillage des environnements, donc tous les tools qu’on est capables de donner à nos IA, font qu’on va perdurer pendant pas mal de temps dans cette croissance exponentielle.

Autrement dit, demain, on aura des modèles meilleurs que ceux d’aujourd’hui. Du coup, ça pose pas mal de questions, et notamment la première : qu’est-ce qu’un développeur ?

C’est une question intéressante à se reposer pour comprendre ce qui est en train de changer. Moi, le développeur, je le définis plutôt comme une personne capable de résoudre des problèmes à l’aide de logiciels et qui va mobiliser les principes du génie logiciel pour analyser, concevoir, tester, déployer et maintenir des systèmes.

Tous ces points-là sont super intéressants. Développeur, on ne fait pas qu’écrire du code. On en écrit beaucoup, mais on ne fait pas que ça.

On est capables de transformer un besoin, des contraintes, des arbitrages en un système qui fonctionne. On répond à un besoin client, et tout ça, ça peut évoluer. Et surtout, demain, le système, il faut qu’on soit aussi capables de le maintenir.

L’IA, la danse qu’elle est en train de faire, c’est qu’elle déplace ce centre de gravité. Parce qu’aujourd’hui, elle produit quand même une part importante du code.

Je vous l’ai dit au début : j’ai essayé de pousser le curseur à fond. Quand je lance un agent, c’est l’IA qui fait. Moi, je n’ai pas écrit le code : j’ai eu l’idée de la feature, elle a fait la feature, elle l’a développée, elle l’a écrite.

Et ça, ça marche bien quand le problème est déjà bien cadré, quand il est déjà documenté, quand on est sur des sujets connus, plutôt proches de ce qu’on lui demande de faire. Le truc final, là-dedans, qui est intéressant, c’est que la vitesse de frappe quand vous êtes derrière votre clavier, ce n’est plus du tout un bottleneck.

Aujourd’hui, vous pouvez taper lentement du code. En fait, on se retrouve à peu près tous à faire les choses à la même vitesse.

Et ce petit changement, qui n’a l’air de rien, le fait qu’on n’écrive plus le code à la main, a des conséquences énormes. Et c’est à partir de ça que découle toute la suite.

Jusqu’à aujourd’hui, on écrivait du code. On faisait de la production ligne à ligne de notre code, mais ce n’est plus le cas.

Ce n’est pas parce que l’écriture du code devient moins chère que le logiciel devient plus simple à produire. On l’a vu tout à l’heure sur ce qu’était un développeur, un ingénieur logiciel : c’est beaucoup plus qu’écrire du code.

Et ça, c’est hyper important de s’en souvenir, notamment quand on vous dit que le développeur est mort. La partie écriture du code, oui, peut-être ; le reste, c’est encore une question ouverte.

Dans la partie transformation du métier, tout se déplace un petit peu. Puisque si on n’écrit plus le code, ce sont tous les à-côtés qui vont prendre beaucoup plus de place.

On a la partie spécifications qui va peut-être, aujourd’hui, prendre plus de place, puisque si c’est l’IA qui prend en charge l’écriture du code, vous voulez le spécifier correctement pour qu’elle l’écrive le plus possible du premier coup. Tout ce qui est mise en contexte, donc lui donner les bonnes ressources, les bons documents qui vont avec.

Vous avez aussi tout ce qui est évaluation, revue de code. Potentiellement, si vous faites plus de code à lire et qu’elle l’écrit plus vite, ça veut dire plus de code à review.

Il y a aussi tout ce qui est garde-fous : comment s’assurer que l’IA écrit du code qui correspond bien à vos bonnes pratiques, comment vous gardez une cohérence d’ensemble, et comment, ou plutôt qui, garde à la fin la responsabilité du code qui a été écrit. Tout ça, ce sont des changements qui sont en train de se passer.

Finalement, ce qu’on se rend compte, c’est que pour écrire cette conférence, on s’est basés sur différents papiers scientifiques, différents articles de plein d’auteurs et aussi beaucoup d’interviews. Notamment une interview avec Hugo Richard, qui nous dit qu’aujourd’hui, dans son entreprise, il est devenu un orchestrateur.

Il va diriger des agents pour faire des choses, mais lui, en tant que tel, il n’écrit plus le code. Et on a Keith Morris qui nous propose de distinguer plusieurs positions.

Donc c’est ce qu’on voit là. Jusqu’à aujourd’hui, le cycle de vie du développement logiciel, ça ressemblait à ça : on avait une idée, on travaillait dessus, et travailler dessus, ça voulait dire planifier, écrire du code, avec une boucle comme ça.

Avec l’arrivée de l’IA, on a trois possibilités. Il y a trois manières de voir les choses.

La première, c’est de se dire que moi, humain, je vais simplement réfléchir aux choses, les planifier, et ensuite j’ai l’IA qui va tout faire. Ça, c’est globalement du vibe coding : vous ne regardez pas le code, vous ne faites pas de review.

Vous avez ensuite l’humain dans la boucle. Là, vous allez itérer avec l’IA, qui va être au milieu et qui va travailler.

Et puis vous avez le dernier modèle. C’est celui-là que Keith Morris appelle le fait d’être sur la boucle de développement logiciel, où vous allez être à la fois dans la partie conception, puis demander à l’IA d’écrire du code que vous allez review et dont vous allez rester le propriétaire.

Ça, ce sont les trois notions dont il est hyper important d’avoir conscience. Jusqu’à novembre 2023, on n’avait pas le choix que d’être dans la configuration historique. Aujourd’hui, on a plusieurs choix.

Alors quel est le bon choix ? Aujourd’hui, on se rend compte que c’est potentiellement le dernier, peut-être le plus intéressant.

Mais on voit aussi que le vibe coding a des effets intéressants, ou pas, pour la sécurité des sites notamment. Et finalement, ce qu’on se rend compte avec ces trois changements-là, c’est qu’on a un travail d’ingénierie qui monte en abstraction.

C’est-à-dire qu’on n’a plus besoin, ou que ce n’est plus obligatoire, de regarder chaque ligne de code. Là, on va pouvoir accélérer, gagner du temps, mais ça veut dire qu’on monte en abstraction.

Potentiellement, ça peut fonctionner. Et le code, en tant que tel, n’est plus nécessairement la finalité de ce qu’on va produire.

L’autre point intéressant, c’est que quand on écrivait du code, on faisait en réalité deux choses en même temps. On ne s’en rendait pas compte, mais on faisait une partie production, c’est-à-dire qu’on écrivait du code, on modifiait du code existant, on avançait et on arrivait à un résultat final.

Mais en parallèle de tout ce travail-là, il y avait aussi de l’absorption. En prenant son temps pour écrire son code, cette lenteur-là, qu’on considérait comme une lenteur, nous permettait en réalité de comprendre ce qu’on faisait.

Elle nous permettait de représenter dans notre tête un petit peu comment les systèmes fonctionnaient et de nous forger des modèles mentaux, c’est-à-dire des versions simplifiées du système qui nous permettaient, au moment où le client venait nous voir avec une problématique, de nous dire : « Ok, là ça passe, là ça ne passe pas, là on peut le faire », parce qu’on avait ces versions simplifiées, ces abstractions qu’on pouvait utiliser.

Jusqu’à présent, ces deux processus-là étaient couplés. Parce qu’on arrivait derrière notre clavier, on écrivait notre code, et en fait on absorbait le code.

Aujourd’hui, l’IA les découpe. Elle les découpe parce que la production, ce n’est plus nous qui la faisons.

Donc si ce n’est plus nous qui écrivons le code, on ne peut plus l’absorber. On n’a plus le temps : ça génère beaucoup plus vite que ce qu’on est capables d’absorber.

Et donc le code devient beaucoup moins coûteux à produire qu’à percevoir. La vitesse de la génération augmente beaucoup trop vite par rapport à notre capacité à le lire et à le comprendre, parce que notre vitesse de compréhension, elle, n’a pas été augmentée par l’IA.

Elle reste complètement humaine. Et ça pose beaucoup de questions, notamment celle de la dette cognitive.

Vous avez sûrement déjà toutes et tous entendu parler de la dette technique. C’est cette idée de livrer un petit peu plus vite, de repousser le nettoyage, et la facture arrive un peu plus tard, mais au moins on a livré un peu plus vite.

C’est un trade-off. La dette cognitive, c’est un peu pareil.

On va produire des changements que personne n’a vraiment le temps d’absorber, que personne n’a vraiment le temps de comprendre, que personne n’a vraiment le temps de relire. Donc on a du code qui fonctionne, des tests qui passent, des tickets qui avancent, mais on a une compréhension du logiciel qui diminue.

À court terme, ça peut marcher. Le risque, c’est qu’à long terme on fasse beaucoup plus de livraisons, mais qu’en fait les équipes ne comprennent plus rien à ce qu’elles font.

Même potentiellement que demain, le client… C’est avec la vision qu’on a actuelle de l’IA, puisque potentiellement l’IA deviendra suffisamment bonne pour qu’on n’ait plus ces problématiques-là. Aujourd’hui, en tout cas, ça reste un risque qui a beaucoup été discuté.

Le problème, c’est que là on parlait beaucoup de l’écriture du code en tant que personne individuelle. On arrivait derrière notre ordinateur, on se posait, on écrivait du code.

Mais ça va beaucoup plus loin que juste nous, à notre échelle individuelle : ça arrive au niveau des organisations. Parce que dans les organisations, vous avez des métriques, des KPI, qui vous permettent de savoir à quel point vous avancez vite.

Aujourd’hui, ces métriques sont principalement temporelles, basées par exemple sur le temps de review. Est-ce que vous êtes capables de review suffisamment vite les PR, ou est-ce que ça prend trop de temps ? Il faudrait peut-être accélérer.

Est-ce que vous avez une vélocité ? Est-ce que vous passez de mon ticket JIRA à sa mise en production suffisamment vite ? Est-ce que vous livrez suffisamment de features ?

Et si on prend par exemple DORA, notamment avec son critère sur le change lead time, donc votre capacité à passer d’un ticket à sa mise en production, est-ce que ça, vous le faites suffisamment vite ? Avec l’IA, en fait, vous pouvez compresser le temps de tout ça, au coût de la compréhension.

Donc aujourd’hui, on a des métriques dans nos entreprises qui sont beaucoup axées sur la vitesse. Et des gens qui ne sont pas forcément familiers du métier vont potentiellement lire ces métriques-là, se dire : « Avec l’IA, diminuez ces métriques-là », et vous allez les diminuer.

Mais vous ne comprendrez plus rien à votre code. Et donc, potentiellement, ça veut dire que les métriques qui nous servaient hier, il faut totalement les revoir.

Et justement, DORA a sorti une version actualisée 2025 avec la prise en compte de l’IA. Et moi, ça me rappelle beaucoup cette image-là : « Quelle est votre qualité principale ? — Je suis très rapide en calcul mental. — Ok. 26 x 564 ? — 57. — C’est faux. — Ouais, mais c’était rapide. »

Avec l’IA, finalement, c’est un peu la même chose. J’ai livré vite, mais je n’ai rien compris. Mais ça marche.

Et ça, c’est un vrai danger auquel il faut faire attention, notamment parce que les demandes vont beaucoup venir du haut. Les gens au-dessus, le management, vont vouloir que vous alliez plus vite.

En fait, il va falloir un peu résister, parce que ce n’est pas si simple. L’équation, ce n’est pas juste « je livre plus vite ».

En faisant tout ça, on déplace le goulot d’étranglement qui, aujourd’hui, était nous, notre capacité à écrire du code. On embauchait beaucoup de personnes justement pour pouvoir produire beaucoup plus.

En fait, on déplace ce goulot d’étranglement-là. Beaucoup plus de code, donc on a des problèmes à la review.

Aujourd’hui, prenez un junior par exemple, qui utilise l’IA. Un junior n’est pas forcément encore prêt à review des PR, et pourtant il va vous produire du code.

Il faut l’assumer derrière, il faut le review. Donc qu’est-ce qu’on fait ? Qu’est-ce qu’on met en place ? Est-ce qu’on utilise aussi des agents IA pour review tout le code, faire des premières passes, faire des premières itérations ?

On est aussi les premiers avec la QA. Si on produit encore plus de features, est-ce que la QA va être capable de l’assumer ?

Ça pose aussi des questions en parlant de ticket, de qualité de contexte, de décision produit. Comment est-ce que le PM arrive à nous en donner suffisamment ?

Comment on fait pour ne pas s’ennuyer dans notre travail ? Même si je pense qu’on a ce qu’il faut pour s’occuper, en tout cas ça pose des questions là-dessus.

Et finalement, au global, le dernier point le plus intéressant, c’est : quelle est la capacité de l’organisation à absorber ? Parce que ça pose aussi potentiellement des questions juridiques sur certaines fonctionnalités, des questions RH, des questions de discussion avec le client.

Et ça, c’est une pression qui se déplace. Aujourd’hui, elle était sur la production ; aujourd’hui, elle est plus vers le contrôle.

Et on a Anivela qui va encore plus loin dans ce questionnement-là, et qui se demande : même quand l’ingénierie produit plus vite, le reste du système ne suit pas nécessairement. Et donc les décisions, la coordination, marchent elles-mêmes à une vitesse humaine.

En fait, nous, on absorbe à une vitesse humaine. Donc on produit à une vitesse IA, peut-être 10 fois plus vite, mais nous, on absorbe à une vitesse humaine.

Et donc ce qu’elle formule, c’est : est-ce que l’humanité est prête pour autant de logiciels ? Prenez un exemple concret : vous développez un logiciel et vous rajoutez 10 features par jour.

Votre client, il va falloir lui expliquer ces 10 features-là que vous livrez par jour. Il va falloir qu’il les prenne en main, qu’il les utilise, qu’il les mette en place dans son workflow.

En fait, est-ce que vraiment on est capables, nous, humains, d’assumer tout ça ? C’est une question.

Si on reprend un petit peu cette idée d’humain sur la boucle, il y a une autre chose qui se passe et qui est intéressante à remarquer : on avait une expérience un peu intime avec notre métier. Cette idée d’écrire du code, il y avait un truc un peu intime.

Et en fait, on a des nouvelles fatigues aujourd’hui qui se créent. Le fait de superviser un agent, d’avoir des retours d’agent à lire, des chatbots à lire, de passer d’agent en agent, des choix à arbitrer, l’agent nous demande des trucs.

Il faut comprendre toute sa réflexion. Il faut être hyper critique sur les sorties plausibles, mais qui en réalité sont fausses, donc il faut aussi les détecter.

Tous ces trucs-là, ce sont des choses dont on n’a pas forcément l’habitude, sur lesquelles on ne s’est pas formés, sur lesquelles on n’a pas passé du temps à apprendre. Et donc aujourd’hui, ça crée des nouvelles fatigues.

C’est ce qu’on ressent et ce que les gens disent dans leurs articles. En changeant le métier, c’est comme si un sportif changeait de discipline.

Il faut tout réapprendre. Et donc aujourd’hui, c’est très fatigant.

Et puis il y avait une autre dimension, qui était celle de la récompense. Quand on ferme un ticket, quand on corrige un bug, quand on livre une fonctionnalité, on a cette petite récompense qui nous fait plaisir.

Mais aujourd’hui, avec l’IA, on peut en avoir à l’infini, et hyper rapidement, des petites récompenses. Donc itérer plus vite, c’est aussi potentiellement avoir un rapport avec l’outil de manière beaucoup plus compulsive.

On va manger ? Attends, je lance un petit agent. Un deuxième. On y passe après.

Jusqu’au moment où tout ça nous demande beaucoup trop de charge mentale, ça devient trop difficile et on se fait rattraper par ça.

Et puis, dans les autres transformations du métier, l’IA agit comme un amplificateur. Au tout début du vert, à gauche, ou au tout début du rouge, il n’y avait pas une différence énorme entre ces deux organisations-là.

Mais comme l’IA va venir tout amplifier, elle va venir amplifier aussi bien vos qualités à titre individuel qu’à titre d’organisation. Donc vous allez arriver tout en haut à droite dans le vert, mais aussi vos défauts.

Donc si vous aviez des process qui ne marchaient pas très bien, l’IA va les révéler de manière hyper forte, pour ne pas dire exponentielle. Et donc c’est un sujet sur lequel il faut avoir conscience.

Sur la question du junior, deux visions s’opposent. La première, c’est : c’est fini pour eux, ce sont clairement les premières victimes et la pipeline du recrutement est cassée pour les 10 prochaines années.

Ça, c’est une première vision. Elle n’est pas très optimiste.

La deuxième, c’est que ça ne va pas changer grand-chose, parce qu’il ne faut pas confondre ce qu’est le développeur et le fait de taper du code. Ça pose quand même des questions parce que, si l’IA fait les tâches simples qu’on donnait aux juniors, bon.

Aujourd’hui, ce sont ces deux visions-là qui s’opposent. Il n’y a pas encore de réponse, d’autant plus qu’aujourd’hui le marché est très difficile à analyser à cause de tous les soucis géopolitiques mondiaux et économiques.

Et puis enfin, pour réussir à former un junior aujourd’hui, jusqu’à présent on lui donnait ces petites tâches qu’aujourd’hui on donne à l’IA. Si on dit à un junior de faire quelque chose et qu’il utilise l’IA, il va peut-être réussir à le faire, très certainement même.

Mais il ne va pas forcément être capable de l’expliquer, de le défendre et de le maintenir sur la durée. Je parle des juniors, mais en vrai ça peut très bien être pareil pour nous quand on rentre dans un nouveau domaine.

Et donc ça crée ce qu’on appelle des experts fragiles : des gens qui donnent l’impression qu’ils maîtrisent et, en fait, si tu creuses, il n’y a plus rien. Et ça, c’est un vrai souci.

Ça pose la question de comment, du coup, on forme ces juniors-là maintenant, si on ne peut plus leur donner les petites tâches. Et pour ça, on a l’exposition à l’excellence.

C’est-à-dire leur montrer ce qu’est vraiment du bon code. C’est leur faire des retours humains, pas juste taper sur un chatbot qui est tout le temps d’accord avec eux.

C’est aussi la compréhension des trade-offs, pas juste dire « fais ça ». Non : tu fais ça de cette manière-là parce que c’est plus intéressant que cette autre technique-là, qui aurait pu être utilisée si on avait été dans telle situation.

C’est aussi une responsabilité progressive, donner plus d’importance aux juniors.

Finalement, sur les transformations du métier, ce qu’il faut retenir, c’est qu’on est potentiellement en train de se créer, à vouloir accélérer, une énorme dette cognitive. Ce n’est pas très agréable.

On a tout le goulot d’étranglement qui est en train de se déplacer. Donc quand on vous dit « écrivez du code avec l’IA », oui, mais potentiellement le reste de l’entreprise ne suit pas du tout.

Et puis enfin, vous avez l’amplification des forces et des faiblesses. Tout ce que vous saviez bien faire, vous allez savoir encore mieux le faire, produire encore plus vite.

Mais par contre, tout ce qui était les difficultés que vous pouviez rencontrer va devenir encore plus difficile, et ce seront sûrement des points sur lesquels il faudra travailler à titre individuel ou d’organisation. Et puis enfin, il y a un vrai risque pour les juniors.

Aujourd’hui, on ne sait pas trop encore, mais ce qui est sûr, c’est qu’on ne peut plus leur donner les petites tâches qu’on donne aujourd’hui à des IA. Il faut donc trouver d’autres moyens de les faire monter en compétences.

Parce qu’on entend souvent dire que le métier de développeur va disparaître. En tant que tel, vous n’allez pas perdre votre job.

En revanche, le job que vous avez connu, lui, n’existe plus. La nuance est là, à mon sens.

Elle est subtile, mais elle est hyper importante. Parce que ça veut dire que si vous étiez rentrés dans le métier pour le plaisir d’écrire du code, ça pourrait commencer à devenir un petit peu compliqué.

Maintenant qu’on n’écrit plus de code, si toute l’ingénierie se déplace, ça pose la question de ce qui se passe, d’où on va et de ce que le développeur doit apprendre, doit remettre au centre.

Il y a deux mauvais réflexes à écarter tout de suite. Tout ne va pas devenir du prompting : ce n’est pas la compétence à développer.

Et il ne suffit pas de continuer comme avant, c’est-à-dire écrire son code ligne à ligne, pour se dire qu’on va rester du bon côté de l’histoire. On ne peut pas juste fermer les yeux.

Parce que si produire du code devient de moins en moins cher, ça veut dire que la valeur augmente ailleurs : sur comprendre, sur cadrer, sur juger ce que l’IA a fait, sur le fait d’agir et sur le fait de rester responsable.

Donc les fondamentaux : on entend dire que coder ne sert plus à rien. En fait, coder, ça sert, et même plus profond encore, les fondamentaux servent encore plus aujourd’hui qu’hier.

Jusqu’à présent, on valorisait beaucoup le fait de passer du ticket JIRA à l’implémentation. C’est-à-dire qu’on a embauché des gens pour écrire du code, tout simplement.

Sauf que ça, c’est le truc qu’aujourd’hui l’IA fait. Et donc apprendre les bases devient le truc le plus important.

On a Matteo Collina qui nous en parle très bien dans l’un de ses articles, et qui nous dit que les fondamentaux sont en train de reprendre de la valeur : l’algorithmie, les bases de données, le réseau, les systèmes distribués, l’architecture, la fiabilité, pour justement être capables de voir si ce que l’IA propose est juste, adapté, maintenable et cohérent avec le reste du système.

Aujourd’hui, apprendre les bases, ou réapprendre les bases, ou revoir les bases, ce n’est pas juste pour la partie technique. C’est pour augmenter sa capacité à juger ce que fait l’IA.

En fait, c’est sa capacité de jugement qu’il faut améliorer. Il faut changer.

On a ensuite ce triangle-là, qui est le triangle de l’efficacité. On a en vert le discernement, en orange les capacités techniques et en bleu le pouvoir d’action.

Aujourd’hui, la capacité technique, c’est celle qui s’effondre, parce que c’est justement cette partie-là du « j’écris du code ». Et ça pose quelques problématiques.

Du coup, la capacité de discernement devient très importante. C’est celle de reconnaître justement l’excellence, la capacité à distinguer une solution robuste d’une solution fragile, une bonne abstraction d’une abstraction inutile, ou un prototype convaincant d’une dette technique.

Pour autant, ce n’est pas parce que cette partie-là s’effondre, la partie capacité technique, que la technique a disparu. C’est juste un socle qui devient de moins en moins visible, d’où la montée en abstraction, pour renforcer le discernement et le pouvoir d’action.

Parce que l’IA augmente justement cette valeur du jugement. Et on juge mieux quand on a déjà codé, quand on a déjà cassé des systèmes, quand on a déjà maintenu un système sur la durée, ou quand on a pris une mauvaise décision et qu’il faut l’assumer six mois plus tard.

On est beaucoup plus forts pour juger, et pour juger ce que l’IA nous sort.

On parle beaucoup d’agentivité pour les IA, cette capacité qu’ont les IA à faire des choses par elles-mêmes, à prendre des décisions. On parle beaucoup moins de l’agentivité humaine, mais en réalité elle est tout aussi importante.

C’est celle de lancer un prototype, de tester quelque chose, d’explorer une solution, parce qu’aujourd’hui tester quelque chose coûte beaucoup moins cher qu’avant. C’est celle d’avancer, c’est celle d’oser.

Et ça, ça devient une capacité hyper importante, surtout quand produire du code ne coûte plus grand-chose. On a justement Hugo Richard qui nous parlait de sa curiosité.

Aujourd’hui, c’est sa curiosité qui lui permet de continuer à avancer, à explorer ce que fait l’IA, à tester de nouvelles techniques, à mettre en place de nouvelles solutions. On a l’entreprise Alan qui parle aussi du pouvoir d’action, et qui, pour elle, est un point différenciant.

Parce que l’agentivité, ce n’est pas juste faire des trucs plus vite. C’est justement ce courage d’agir.

Et donc ça ne remplace surtout pas la compréhension. On avance, on observe ce qui se passe : j’ai tenté, je regarde, est-ce que ça a marché, est-ce que ça n’a pas marché, est-ce qu’on continue ?

C’est celle de corriger, d’apprendre et de recommencer, et pas juste avancer, avancer, sans jamais regarder en arrière, sans jamais comprendre. Donc c’est la notion d’agir efficacement sur son environnement ou sur soi pour comprendre ce qu’on est en train de faire.

Et puis enfin, l’autre compétence qui devient critique, c’est celle de l’esprit critique. L’une des définitions, c’est l’idée de n’accepter aucune assertion sans s’interroger sur sa valeur.

Et on comprend tout de suite son importance. Quand l’IA vous sort un plan, 300 ou 500 lignes de code, on ne peut pas juste l’accepter.

Et surtout, ça nous protège sur deux niveaux. L’esprit critique, ça nous protège sur les discours un peu simplistes sur l’IA, tous les gourous qui nous disent qu’on est finis et que notre métier est terminé, ou qu’il suffit d’acheter une formation et c’est bon, vous devenez maître de l’IA.

Et puis c’est aussi se protéger contre l’IA elle-même. Là-dedans, on va retrouver le fait d’analyser, d’évaluer, de comparer, de croiser ses sources, de questionner les hypothèses, de ne pas juste dire oui, oui, oui sans jamais se remettre en question, et puis d’accepter aussi de ne pas tout savoir tout de suite.

Donc sur la partie évolution des compétences, on voit que maîtriser les bases revient sur le devant de la scène pour apprendre à juger, que juger avec discernement, c’est reconnaître l’excellence, que travailler l’agentivité, donc travailler cette curiosité et cette mise en mouvement, est important, et puis que c’est renforcer son esprit critique pour utiliser l’IA sans cesser de penser.

Il y a cette magnifique expression : la vigilance émerveillée. C’est l’idée de dire que l’IA, c’est un truc vers lequel on peut aller, sur lequel on peut se dire que c’est assez incroyable, sans non plus partir dans quelque chose de mystique, et en restant aux aguets du fait que ça a des conséquences sur ce qu’on est en train de faire.

Et donc si toutes ces compétences-là changent, si le code perd de la valeur mais que le jugement, par exemple, en prend d’autres, c’est quoi la suite ? Comment est-ce qu’on développe ces nouvelles compétences, et comment est-ce qu’on continue à apprendre en tant qu’individu, mais aussi au sein d’une organisation ? Comment on monte en compétences ?

Ça se passe par différentes étapes. Il faut voir ces étapes comme quelque chose de haut niveau, qui vous permet de vous resituer et de comprendre un petit peu les choses de manière macro, plus que comme quelque chose de vraiment concret que vous devez faire. Ce n’est pas nécessairement un plan à suivre.

Dans la première partie, sur l’IA engagée, l’idée, c’est de se dire qu’on a l’IA qui rentre dans le quotidien, qu’on s’en sert pour résumer un document, pour générer un test, pour débugger un bug. Mais à ce stade-là, dans les organisations ou à titre individuel, l’enjeu, ce n’est pas le ROI.

Ce n’est pas d’avoir un retour sur investissement de ce que vous êtes en train de faire. C’est simplement d’avoir une base commune, donc un langage partagé, pour que tout le monde comprenne un petit peu ce qu’est l’IA, quels sont les enjeux et quelles peuvent être les transformations.

Par exemple, au sein des organisations, ce qui peut se faire, c’est des mini-conférences internes, des labs, donc des espèces de cours à plusieurs, des workshops. Des structurations où ils vont s’organiser par groupes et se dire : ok, nous, on maîtrise l’IA et on va aider les gens à monter en compétences, on va diffuser les news, on va simplifier et on va faire en sorte que tout le monde ait justement les retours d’expérience des autres.

On a même, chez Vercel par exemple, des demo days, où il y a une culture dans l’entreprise qui demande aux gens d’expérimenter, et où c’est ok de prendre du temps sur son temps de travail pour tester des choses avec l’IA. Parce qu’au final, si l’entreprise distribue juste des licences, ça ne va pas du tout aider les gens à monter en compétences.

On a ensuite ceux qui sont enabled. Là, l’idée, c’est de commencer à intégrer l’IA dans des workflows pour transformer la manière de travailler.

Donc une fois qu’on a une base un petit peu plus commune, c’est : qu’est-ce qu’on met en place ? Qu’est-ce qu’on met en place notamment pour le contexte ?

On a Sonil Pei qui parlait du contexte, qui devient vraiment le travail. Donc c’est rendre explicites les intentions, les contraintes, les arbitrages, les contraintes de validation. Ça passe aussi par la documentation.

Et puis enfin, la dernière composante, c’est carrément intégrer l’IA dans toute la chaîne de production. Donc c’est, de manière plus concrète, réussir à enrichir par exemple un ticket par l’IA, du code qu’on peut générer encore plus vite avec plus de contexte.

C’est l’idée de démarrer un projet, mais de ne pas démarrer un projet sans ses skills, sans ses MCP, et ainsi de suite. Ça, c’est un fantasme pour beaucoup de gens, puisque c’est cette idée qu’on a un ticket, on claque des doigts et ça part en prod.

On en est encore un peu loin. Et pour beaucoup, c’est aussi un fantasme parce que notre travail reste quand même très collectif et surtout traversé par des contraintes de qualité, de sécurité et de coordination.

Donc cette étape-là pose aussi la question de quelles frictions est-ce qu’on veut absolument garder dans notre travail.

Et puis enfin, au niveau individuel, ça pose la question de comment est-ce que nous, on continue à apprendre des choses, comment est-ce qu’on utilise l’IA. Parce que la question, ce n’est pas juste utiliser l’IA, c’est comment on apprend avec elle sans abandonner sa compréhension.

Donc pour ça, ça veut dire rester à jour, mais aussi filtrer, parce qu’on ne peut pas tout suivre. On le voit, il y a une grosse news par jour, on ne peut pas tout faire.

Et puis c’est aussi éviter de transformer l’IA en substitut permanent à l’effort de compréhension. À tout déléguer à l’IA, je m’en rends compte, je deviens un peu bête.

Et puis c’est justement toute cette partie de skill atrophy. C’est cette idée que nos compétences, à force de les déléguer à des IA, disparaissent petit à petit, et que le jour où on en a besoin, en fait, on ne sait plus faire.

Faites le test chez vous : pendant un mois, essayez de ne plus écrire de code par vous-mêmes. Et ensuite, réessayez d’écrire du code. C’est hyper dur.

Je n’ai pas réussi à revenir. Et donc c’est vraiment cette idée que produire sans absorber ce que vous produisez devient dangereux.

C’est être conscient de tout ce qui est généré et s’appuyer sur d’autres humains, pas seulement sur des IA. Et dans toute cette montée en compétences-là, il faut regarder ces trois étapes principales et surtout garder cette idée de rester en mouvement aussi à titre individuel.

Si on fait un petit récap de tout ce qu’on a vu, on a vu que le métier était en train de changer, que le métier qu’on a connu jusqu’à présent n’était plus le même que celui d’aujourd’hui, et encore moins que celui de demain.

Avec cette partie de création potentielle de dette cognitive dans le métier, de déplacement de goulots d’étranglement : ce ne sera potentiellement plus vous qui serez le problème, entre guillemets, mais la QA peut être fortement ralentie, les reviews aussi, ou simplement le PM qui aurait à vous donner suffisamment de tickets.

L’amplification des forces et des faiblesses, donc s’il y avait des problèmes structurels dans les process, en fait ça va devenir encore pire, et puis un risque pour les juniors.

Sur l’évolution des compétences, on a vu que maîtriser les bases va devenir hyper important, non pas pour le plaisir de maîtriser les bases, mais vraiment pour pouvoir juger avec discernement ce que l’IA nous produit. Travailler l’agentivité, sa capacité à faire des choses, à avancer, est hyper important.

Et puis enfin, renforcer l’esprit critique. À mon sens, ce point-là, c’est vraiment le plus important.

De manière générale, renforcer l’esprit critique est une compétence essentielle. Et sur la montée en compétences, on l’a vu juste avant.

Finalement, s’il y avait des choses à retenir de cette conférence, c’est ça : on est dans une période de transformation assez intense. C’est-à-dire qu’aujourd’hui, vous êtes peut-être venus ici en vous disant : trop bien, il va nous donner plein de réponses.

Je n’ai pas donné tant de réponses que ça. J’ai peut-être soulevé beaucoup plus de questions, en réalité, parce qu’on ne sait pas ce qui va arriver.

Et tous les gens qui vous disent : moi, je sais, c’est sûr, c’est ça qu’il faut faire, non. En fait, aujourd’hui, il faut essayer, il faut tester, il faut voir ce qui marche, ce qui ne marche pas. Et potentiellement, ce qui marche aujourd’hui ne marchera plus demain.

Les juniors ont aujourd’hui toute leur place et, surtout, vous devez rester vigilants en étant émerveillés. Et ça, c’est le mieux.

Parce que peut-être qu’en fait, comme aujourd’hui personne n’a de réponse, peut-être qu’aujourd’hui cette conférence, en tout cas je l’espère, c’est simplement le début d’une longue conversation. J’espère que ça va vous donner des sujets pour pouvoir discuter entre vous de tout ça.

Je voulais remercier Julie parce que, même si elle n’est pas là aujourd’hui, c’est elle qui a écrit en grande partie le plan, et c’est grâce à elle que la conférence existe. Donc merci Julie.

Je voulais remercier aussi les gens qui m’ont donné de leur temps pour faire les interviews : Hugo, Lior, Greg, Greg notamment qui a une communauté qui s’appelle DevWithAI que je vous invite à rejoindre, Julien et Mathieu qui travaillent à Infomaniak, et puis Thomas.

Et puis enfin, c’est la fin. Donc c’était Estéban Soubiran. Si vous voulez faire un petit feedback, ce serait trop cool. Si vous voulez venir en discuter aussi, pareil. Et sinon, merci à tous !