L'IA va-t-elle tuer nos métiers ? L'histoire dit non : Elle les transforme

Arrêtons-nous une seconde sur le bruit ambiant.

"L'IA va remplacer les développeurs." "Dans cinq ans, coder sera un métier obsolète." "ChatGPT fait déjà le travail d'une équipe entière." Ces phrases, vous les avez lues, entendues, peut-être même prononcées. Elles circulent dans les conférences tech, les threads LinkedIn, les réunions de direction. Elles génèrent de l'anxiété, des reconversions précipitées, des débats sans fin.

Mais voilà ce qu'on oublie systématiquement dans ces discussions : nous avons déjà vécu ça dans la tech.

Dans les années 50, des hommes et des femmes se levaient chaque matin pour aller au bureau faire des calculs. Des calculs complexes, rigoureux, essentiels :

• trajectoires balistiques,
• simulations aéronautiques,
• projections astronomiques.

Leur titre : calculateur humain. Leur crainte, quand les premiers ordinateurs électroniques sont arrivés : exactement la même que celle du développeur d'aujourd'hui face à l'IA.

Qu'est-il arrivé à ces calculateurs humains ? Certains ont disparu. D'autres sont devenus les premières programmeuses ou premiers programmeurs de l'histoire. Et ceux qui ont su lire le changement avant les autres “comme Dorothy Vaughan à la NASA” (source wikipédia) sont devenus indispensables précisément parce que la machine était là.

L'histoire ne se répète pas exactement. Mais elle rime. Et elle a beaucoup à nous apprendre sur ce qui nous attend.

Il était une fois... les calculateurs humains

Rembobinons un peu le temps. Nous sommes dans les années 40. La Seconde Guerre mondiale vient de se terminer, et la course à l'espace commence. Les États-Unis ont besoin de calculs. Des milliers de calculs. Des trajectoires de missiles, des orbites satellites, des simulations aérodynamiques d'une précision absolue.

Des données dont dépendent des vies et bientôt, des missions spatiales entières.

Pour faire ces calculs, il n'y a pas d'ordinateur. Il y a des humains et il en fallait beaucoup (des salles entières).

Ils s'appellent “calculateurs humains” (source wikipédia).

Leur outil de travail : un crayon, une règle à calcul voire une calculatrice mécanique, et une rigueur mathématique à toute épreuve.

(Mechanical calculator source wikipedia)

Leur bureau : des rangées de tables alignées, des piles de feuilles, un silence de salle d'examen.

Leur valeur : irremplaçable. Sans eux, pas de balistique.

Sans eux, pas d'aéronautique. Sans eux, la NASA n'existe tout simplement pas.

Ce n'est pas un métier de l'ombre ou une anecdote folklorique. C'est une profession structurée, hiérarchisée, hautement qualifiée. On y fait carrière. On y progresse. On y forme des équipes entières. À la NASA, ces équipes sont majoritairement composées de femmes, des mathématiciennes brillantes reléguées à des postes que les hommes ne voulaient pas occuper, mais dont personne ne pouvait se passer.

Et puis, un jour, l'IBM 7090 débarque (source wikipédia).

La scène que tout le monde devrait voir

Si vous n'avez pas vu “Les Figures de l'ombre” (source wikipédia), je vous le conseille. Pas maintenant certes, finissez de lire cet article d'abord. Mais ce soir, regardez-le.

Le film raconte l'histoire vraie de Katherine Johnson, Mary Jackson et Dorothy Vaughan, trois calculatrices humaines afro-américaines à la NASA dans les années 60. Trois femmes qui se battent chaque jour contre le racisme et le sexisme d'une époque qui ne leur laisse aucune place. Un film fort, nécessaire, bouleversant.

Mais c'est aussi et c'est moins souvent dit : un film sur ce moment précis où une machine arrive et change tout.

La scène clé ne dure que quelques minutes. Dorothy Vaughan se retrouve face à l'IBM 7090. Autour d'elle, ses collègues s'inquiètent. On entend les questions que vous avez peut-être vous-même posées récemment : "Est-ce que cette machine va nous remplacer ? Est-ce qu'on va perdre nos postes ?"

Dorothy, elle, ne pose pas ces questions-là.

Elle regarde la machine. Elle comprend ce qu'elle voit. Et elle prend une décision que peu de ses contemporains ont eu le réflexe de prendre : elle va à la bibliothèque, elle emprunte un manuel de FORTRAN, et elle apprend à programmer l'IBM 7090. Seule. Le soir. Avant que quiconque ne lui demande de le faire.

Puis elle forme son équipe.

Ce qui s'est vraiment passé

Alors, les calculateurs humains ont-ils tous perdu leur emploi du jour au lendemain ? Non.

La réalité est plus complexe et beaucoup plus intéressante que le récit catastrophiste qu'on aurait pu écrire à l'époque.

Certains, oui, n'ont pas fait la transition. Ceux qui ont attendu qu'on leur explique quoi faire, qu'on leur propose une formation, qu'on leur garantisse un avenir. Ceux qui ont subi le changement plutôt que de l'anticiper.

Mais les autres, ceux qui ont compris que la machine ne remplaçait pas le cerveau, “elle remplaçait la tâche” sont devenus les premières programmeuses de l'histoire. Les premiers analystes systèmes. Les premiers ingénieurs en informatique. Des métiers qui n'avaient pas de nom cinq ans plus tôt.

Qu'est-ce qui a disparu ? La partie mécanique et répétitive du travail : aligner des chiffres, appliquer des formules, transcrire des résultats.

Qu'est-ce qui est resté ? Le jugement, la vérification, la compréhension des enjeux, la capacité à questionner un résultat qui semble faux. Tout ce qu'une machine, aussi puissante soit-elle, ne peut pas faire seule.

Et Dorothy Vaughan, dans tout ça ? Elle est devenue la première superviseuse afro-américaine de la NASA. Précisément parce qu'elle avait compris, avant tout le monde, que la bonne question n'était pas "est-ce que la machine va me remplacer ?" mais "qu'est-ce que je fais que la machine ne peut pas faire ?"

Soixante ans plus tard, on se pose encore la mauvaise question.

Aujourd'hui, le même scénario avec l'IA ?

Revenons à notre développeur face à GitHub Copilot.

Il vient de générer une fonction en dix secondes. Propre, lisible, fonctionnelle. Il la copie, il la colle, il passe à la suite. Sa vélocité a doublé. Son ticket Jira passe en "Done". Son manager est content.

Mais posons la question qui dérange : est-ce qu'il a compris ce qu'il vient de faire ?

L'illusion du “développeur augmenté”

Il y a un mot qui revient en boucle dans tous les discours sur l'IA et le développement. Un mot rassurant, presque magique : augmenté. Le “développeur augmenté”. Plus rapide, plus productif, plus puissant. L'IA comme super-pouvoir.

C'est séduisant. C'est vendeur. Et c'est, au moins en partie, une illusion.

Non pas parce que l'IA ne rend pas les développeurs plus rapides, elle le fait, indéniablement. Mais parce que vitesse et compréhension sont deux choses très différentes. Et confondre les deux, c'est exactement le piège dans lequel il est facile de tomber.

Imaginez un calculateur humain des années 50 à qui on aurait donné une machine capable de faire ses calculs automatiquement, sans lui expliquer les mathématiques derrière. Il aurait produit des résultats plus vite. Beaucoup plus vite. Mais au premier cas limite, à la première anomalie, à la première situation que la machine n'a pas prévue... il aurait été incapable de détecter l'erreur. Parce qu'il n'aurait pas su ce qu'il cherchait.

C'est exactement ce que décrit l'article d'OCTO sur l'illusion du développeur augmenté : la productivité visible cache une dette de compréhension. On livre plus. On comprend moins. Et cette dette-là, elle ne se voit pas dans les métriques, jusqu'au jour où elle explose.

L'augmentation n'est pas automatique. Elle se mérite. Elle demande de rester acteur de ce qu'on produit, même surtout quand c'est la machine qui tape.

Le tigre dans le moteur agile

L'impact de l'IA ne s'arrête pas à l'acte de coder. Il remonte plus haut. Beaucoup plus haut.

Les rituels agiles que vous pratiquez depuis des années : le sprint planning, le daily, la rétro, la démo, ont été pensés pour des équipes qui produisent à une certaine cadence, avec une certaine granularité de tâches.

Introduisez l'IA générative dans cette équation, et tout le rythme se dérègle.

Une fonctionnalité qui prenait trois jours en prend maintenant un. Un ticket estimé à cinq points en vaut peut-être deux. La définition de "fini" devient floue quand c'est une IA qui a écrit la moitié du code. Et la question de la responsabilité : qui valide, qui arbitre, qui assume ? devient plus épineuse que jamais.

C'est ce que raconte l'article d'OCTO sur l'IA dans le développement agile : l'IA n'est pas juste un outil de plus dans la boîte. C'est un tigre dans le moteur, une force qui propulse et qui bouscule simultanément.

Et face à ce tigre, le développeur de demain ressemble de moins en moins à quelqu'un qui code et de plus en plus à quelqu'un qui orchestre (ex: Liza, BMAD, Cline). Qui pose les bonnes questions. Qui valide les bons résultats. Qui comprend le contexte métier que la machine ne connaît pas. Qui prend les décisions que l'IA ne peut pas prendre seule.

Un rôle plus complexe. Plus exigeant. Et soyons honnêtes bien plus intéressant.

Alors, remplacé ou transformé ?

Reposons la question directement.

L'IA va-t-elle remplacer les développeurs ? Sur certaines tâches, oui. Générer du boilerplate, compléter du code répétitif, rédiger de la documentation, produire des tests unitaires sur des cas standards tout ça, l'IA le fait déjà, et elle va continuer à le faire de mieux en mieux.

Mais comprendre pourquoi une architecture tient ou ne tient pas. Arbitrer entre deux approches techniques selon un contexte métier spécifique. Expliquer à un client pourquoi sa demande crée une dette technique invisible. Détecter qu'un code généré est fonctionnel mais dangereux. Décider que la bonne réponse technique est "non" ça, l'IA ne le fait pas.

Pas encore. Peut-être jamais complètement, cela fait partie des grands mystères qu’il faudra étudier.

Et c'est précisément là que le parallèle avec Dorothy Vaughan devient éclairant. Ce qu'elle a compris en voyant l'IBM 7090, ce n'est pas que son métier disparaissait. C'est que la partie mécanique de son métier disparaissait et que tout le reste prenait soudainement infiniment plus de valeur.

La machine calcule. L'humain décide ce qu'il faut calculer, pourquoi, et ce qu'on fait du résultat.

En 1962 comme en 2024, c'est cette partie-là qui ne se délègue pas.

Ce que l'histoire nous enseigne vraiment

Si vous pensez que ce sentiment d'inquiétude face à une machine qui fait votre travail est une spécificité de notre époque, voici une mauvaise nouvelle : vous avez un siècle de retard.

Parce que cette histoire, on la rejoue en boucle. Avec des acteurs différents, des technologies différentes, des métiers différents. Mais le scénario, lui, ne change pas.

Le même film, encore et encore

Regardez ce tableau. Regardez-le vraiment. Il retrace des changements qui ont eu lieux sur les 100 dernières années, mais nous pourrions remonter plus loin dans le temps et voir toujours le même processus.

Certains avaient raison. Le métier tel qu'ils le pratiquaient a disparu.

Mais voilà ce qu'on ne dit jamais dans les articles catastrophistes : les gens, eux, ne sont pas morts. Ils ont évolué, pivoté, grandi. Souvent vers des rôles plus intéressants, mieux rémunérés, plus proches de la valeur réelle qu'ils apportaient.

On peut prendre comme comparaison l'industrialisation de l'agriculture en France. En 1789, nous avions entre 75 et 80 % de la population active dans l'agriculture. Ce chiffre tombe à 40-45 % en 1900 (source INSEE, INED). La population ayant bien évidemment augmenté entre ces deux dates, ce chiffre permet tout de même de montrer que le « marché » du travail n'est pas quelque chose de figé. Tout évolue et change.

Trois vérités que ce tableau révèle

Première vérité : la panique est une constante, pas un signal.

À chaque décennie, les mêmes discours. Les mêmes titres de presse. Les mêmes experts qui annoncent la fin d'une profession. Et à chaque décennie, la réalité s'avère plus nuancée que la prédiction. Ce n'est pas une raison de ne pas prendre l'IA au sérieux, c'est une raison de ne pas la prendre dans la panique.

Deuxième vérité : ce qui disparaît, c'est toujours la même chose.

Regardez la colonne "Métier menacé". Qu'est-ce qui se cache derrière chaque entrée ? Toujours la même chose : une tâche répétitive, mécanique, qui ne demande pas de jugement. Jouer la même partition chaque soir. Crier les mêmes nouvelles dans la rue. Taper le même type de courrier à longueur de journée. Calculer les mêmes formules sur du papier millimétré.

Ce n'est pas le métier qui disparaît. C'est sa partie la plus automatisable. Et cette partie-là, franchement est-ce qu'on la pleure vraiment ?

Troisième vérité : les nouveaux métiers étaient inimaginables avant.

En 1985, si vous aviez dit à une dactylo qu'elle allait devenir "office manager" ou "assistante de direction polyvalente", elle n'aurait pas compris ce que ces mots voulaient dire. En 1995, personne ne cherchait un "UX designer" ou un "community manager". En 2010, le titre de "data scientist" n'existait pas.

La colonne ??? de 2024 n'est pas vide parce qu'on ne sait pas. Elle est vide parce que les mots pour nommer ces métiers n'existent pas encore. Mais ils existeront. Et dans dix ans, ils paraîtront aussi évidents que "développeur full-stack" vous paraît évident aujourd'hui.

Ce que l'IA prend. Ce que l'IA ne prend pas.

Soyons précis. Parce que "l'IA ne remplace pas les humains" est un discours aussi paresseux que "l'IA va tout remplacer".

Ce que l'IA prend en charge, et c'est déjà le cas :

• Générer du code à partir d'une description
• Compléter des patterns syntaxiques connus
• Produire de la documentation
• Rédiger des tests sur des cas standards
• Répondre à des questions techniques fréquentes

Ce que l'IA ne fait pas, pas vraiment, pas encore :

• Comprendre pourquoi une fonctionnalité existe dans ce contexte métier précis
• Décider qu'une architecture qui fonctionne est quand même une mauvaise idée
• Sentir qu'un client dit une chose mais en veut une autre
• Assumer la responsabilité d'un choix technique devant une équipe
• Dire Non! et expliquer pourquoi c'est la bonne décision

Ce n'est pas anodin. C'est précisément la partie haute du métier. Celle qui crée de la valeur réelle. Celle qu'on sous-estimait parce qu'on était occupé à faire la partie basse.

Ce que Dorothy Vaughan avait compris avant tout le monde

Revenons-y une dernière fois. Pas par nostalgie mais par lucidité.

Dorothy Vaughan n'a pas attendu qu'on lui explique que son métier allait changer. Elle l'a vu venir. Elle a identifié la compétence qui allait devenir critique : la programmation, et elle s'est formée avant que ce soit une nécessité. Avant que ce soit une obligation. Avant que son manager lui demande de le faire.

Et quand l'IBM 7090 a pris en charge les calculs que son équipe faisait à la main, elle n'a pas perdu son poste. Elle a pris de l'altitude. Elle est passée de l'exécution à la supervision, de la tâche à la stratégie, du calcul à la décision.

C'est ça, la vraie leçon. Pas "ne vous inquiétez pas, tout va bien se passer". Mais : ceux qui s'en sortent ne sont pas ceux qui ignorent le changement, ni ceux qui le subissent, ce sont ceux qui l'anticipent.

L'IBM 7090 n'a pas tué Dorothy Vaughan. Il l'a propulsée.

La question, aujourd'hui, c'est de savoir ce que vous allez faire de votre Copilot.

Alors, que faire concrètement ?

Les parallèles historiques, c'est bien. Les leçons de Dorothy Vaughan, c'est inspirant. Mais à un moment, il faut atterrir.

Parce que la vraie question, celle que vous vous posez peut-être depuis le début de cet article, c'est : concrètement, je fais quoi, moi, lundi matin ?

Voilà ce qu'on peut répondre. Selon où vous vous trouvez.

Si vous êtes développeur

La première chose à faire, c'est d'arrêter de mesurer votre valeur en lignes de code produites.

Ce n'est pas l'IA qui rend cette métrique obsolète, elle l'était déjà. Mais l'IA la rend visible.

Quand Copilot génère 200 lignes en trente secondes, la question "combien tu as codé aujourd'hui ?" perd instantanément tout son sens. Et c'est une bonne nouvelle : ça force à se poser la vraie question. Quelle valeur ai-je apportée aujourd'hui ?

Ensuite, résistez à la tentation du copier-coller automatique. Pas parce que le code généré est forcément mauvais, souvent il est bon. Mais parce que comprendre ce que vous livrez, c'est la seule façon de détecter quand ça ne l'est pas.

Un calculateur humain qui recopiait des résultats sans les comprendre ne progressait pas. Il se rendait juste invisible jusqu'au jour où il faisait une erreur catastrophique.

Lisez ce que l'IA génère. Questionnez-le. Modifiez-le. Appropriez-vous-le.

Et surtout, investissez massivement dans ce que l'IA ne fait pas. La compréhension métier. La capacité à cadrer un problème avant de le résoudre. La communication avec des interlocuteurs non-techniques. L'architecture de systèmes complexes. Le sens critique face à un résultat qui semble juste mais qui sent mauvais.

Ce sont ces compétences-là qui vont prendre de la valeur. Pas demain, MAIS maintenant.

Si vous êtes dans une équipe

L'IA ne s'intègre pas dans une équipe comme un nouveau plugin. Elle change la nature du travail collectif, et si vous ne l'anticipez pas, elle va créer des frictions que vous n'avez pas vues venir.

Premier chantier : revisitez ce que "fini" veut dire. Une story complétée avec de l'IA générative, c'est quoi ? Qui valide ? Qui assume ? Ces questions semblent simples. Elles ne le sont pas. Et si vous ne les posez pas maintenant, elles se poseront toutes seules au pire moment.

Deuxième chantier : parlez-en en rétro. Vraiment. Pas pour cocher une case "on a parlé d'IA". Mais pour comprendre comment chaque membre de l'équipe utilise ces outils, ce qu'il en pense, ce qui l'inquiète, ce qui lui fait gagner du temps. Les équipes qui vont s'en sortir ne sont pas celles qui ont les meilleurs outils, ce sont celles qui ont les meilleures conversations sur leurs outils.

Troisième chantier : ne laissez pas les juniors seuls avec l'IA. C'est contre-intuitif, l'IA semble être une aubaine pour monter en compétences rapidement. Et elle peut l'être. Mais elle peut aussi court-circuiter l'apprentissage fondamental. Un junior qui génère du code sans avoir construit les bases ne devient pas senior plus vite, MAIS il devient “senior en carton”. Accompagnez-les. Exigez la compréhension, pas seulement la livraison.

Si vous êtes manager ou recruteur

C'est probablement là que le changement est le plus profond et le moins visible.

Les grilles d'entretien que vous utilisez depuis dix ans sont en train de devenir obsolètes. Tester la capacité d'un candidat à écrire une fonction de tri en quarante-cinq minutes n'a plus beaucoup de sens dans un monde où Copilot le fait en dix secondes. Ce que vous devez évaluer maintenant, c'est autre chose.

On peut se demande :

• Est-ce que cette personne comprend pourquoi elle fait ce qu'elle fait ?
• Est-ce qu'elle sait questionner une solution avant de l'implémenter ?
• Est-ce qu'elle est capable d'expliquer un choix technique à quelqu'un qui ne code pas ?
• Est-ce qu'elle a démontré, à un moment de sa carrière, qu'elle s'était adaptée à un changement qu'elle n'avait pas vu venir ?

Ce dernier point est crucial. Dorothy Vaughan n'a pas attendu qu'on lui propose une formation. Elle a décidé d'apprendre. Cette capacité-là, l'agentivité face au changement, l'apprentissage par initiative propre est probablement la compétence la plus précieuse que vous puissiez chercher aujourd'hui.

Parce que les outils vont continuer à changer. Les langages vont évoluer. Les pratiques vont se transformer. La seule chose qui restera stable, c'est la capacité d'une personne à s'adapter avant qu'on le lui demande.

Recrutez ça. Développez ça. Évaluez ça.

Le reste, l'IA s'en occupe.

Conclusion : L'IA ne tue pas les métiers, elle tue leur version d'hier

Revenons à la question du début.

L'IA va-t-elle tuer les métiers du développement ?

Après cent ans d'histoire technologique, après Dorothy Vaughan et l'IBM 7090, après les musiciens de cinéma muet et les agents de voyage, après les calculateurs humains devenus programmeurs, voilà la réponse honnête : oui et non.

Oui, elle va tuer :

• certaines tâches.
• certaines façons de travailler.
• certaines définitions du métier qui ont cours aujourd'hui et qui seront méconnaissables dans dix ans.

Sur ce point, les Cassandre ont raison.

Mais non, elle ne va pas tuer les développeurs. Pas plus que le cinéma parlant n'a tué les musiciens, pas plus que le tableur n'a tué les comptables, pas plus que l'ordinateur n'a tué Dorothy Vaughan. Elle va tuer leur version d'hier. Et libérer leur version de demain.

C'est “là” que la vraie bifurcation se trouve.

• Pas entre ceux qui utilisent l'IA et ceux qui ne l'utilisent pas.
• Pas entre ceux qui ont peur et ceux qui sont enthousiastes.

La vraie bifurcation, elle est entre ceux qui subissent la transformation et ceux qui la mènent.

Dorothy Vaughan n'avait pas de mentor pour lui dire quoi faire. Pas de roadmap, pas de plan de formation, pas de manager visionnaire qui avait tout anticipé. Elle avait juste une bibliothèque municipale, un manuel de FORTRAN, et la lucidité de comprendre que le monde venait de changer et qu'attendre n'était pas une option.

Elle n'a pas demandé la permission d'évoluer. Elle a évolué.

Ce que l'histoire nous dit, au fond, c'est que les révolutions technologiques ne sont jamais vraiment des fins. Ce sont des élévations forcées. Elles retirent le bas pour mieux révéler le haut. Elles automatisent la mécanique pour mieux valoriser le jugement. Elles accélèrent l'exécution pour mieux rendre visible “enfin” la vraie valeur de ceux qui pensent, qui décident, qui assument.

L'IA générative ne fait pas exception. Elle est simplement la prochaine marche d'un escalier que l'humanité monte depuis au moins un siècle.

Alors voilà ce qu'on peut se dire, concrètement, en refermant cet article.

Ne passez pas les prochains mois à débattre de savoir si l'IA va vous remplacer. Ce débat est aussi stérile que celui que les calculateurs humains auraient pu avoir en 1955. Pendant qu'ils en discutaient, Dorothy Vaughan apprenait le FORTRAN.

Posez-vous plutôt la bonne question. Pas "est-ce que l'IA va prendre ma place ?" mais "quelle place est-ce que je veux prendre dans un monde avec l'IA ?"

La réponse à cette question-là, aucune machine ne peut la générer à votre place.

Et c'est exactement pour ça que vous êtes encore irremplaçable.