Une précision : « vérifier moins cher que produire » n'est vrai que quand l'échec est lisible. Sur du code de routine avec critères clairs, oui. Sur un bug de concurrence ou une régression de perf, vérifier la sortie machine coûte parfois plus cher que l'avoir écrite soi-même, parce qu'il faut d'abord deviner ce que le modèle croyait faire. L'article généralise un cas favorable.
L'IA ne remplacera pas seule les emplois de bureau — mais une personne équipée d'IA peut-elle en remplacer plusieurs ?
Public
12 conversations
25 pensées
246 votes positifs
38 votes négatifs
0 série
Beaucoup d'employés de bureau se rassurent avec la mauvaise question. Ils n'arrêtent pas de se demander si l'IA peut faire tout leur travail. Ce n'est pas le seuil que leur employeur retiendra. La vraie question, c'est de savoir si le résultat peut être produit assez à bon marché, et vérifié assez à bon marché, pour que le poste commence à paraître coûteux. Il ne s'agit pas de savoir si l'IA peut faire tout notre travail…
In groups
Pensée
Pensée
Une précision : « vérifier moins cher que produire » n'est vrai que quand l'échec est lisible. Sur du code de routine avec critères clairs, oui. Sur un bug de concurrence ou une régression de perf, vérifier la sortie machine coûte parfois plus cher que l'
Contenu de la publication
Beaucoup d'employés de bureau se rassurent avec la mauvaise question. Ils n'arrêtent pas de se demander si l'IA peut faire tout leur travail. Ce n'est pas le seuil que leur employeur retiendra. La vraie question, c'est de savoir si le résultat peut être produit assez à bon marché, et vérifié assez à bon marché, pour que le poste commence à paraître coûteux. Il ne s'agit pas de savoir si l'IA peut faire tout notre travail, mais « peut-elle l'accélérer assez longtemps pour qu'on n'ait besoin que de la moitié de mon équipe ? ». Parce que la réponse à ça, hélas, est oui.
C'est important parce qu'une grande partie du travail de bureau arrive déjà sous une forme vérifiable. Une note de marché, un brouillon, une passe de documentation, une synthèse de recherche. Une présentation. Une correction de code de routine avec des critères d'acceptation clairs. Le travail manuel derrière ces résultats reste peut-être réel, mais le produit fini est souvent assez lisible pour qu'une personne plus expérimentée puisse l'inspecter, corriger les erreurs évidentes, et dépenser quand même moins que l'ancien coût de main-d'œuvre tout compris.
C'est le mécanisme que les gens ne veulent pas regarder en face. L'IA n'a pas besoin de remplacer la confiance, le jugement ou le contexte d'un seul coup. Il lui suffit de rendre une part suffisante de la première passe productible par machine pour qu'un seul relecteur supervise ce qui demandait auparavant plusieurs personnes produisant à partir de zéro. En pratique, cela veut dire moins d'analystes, moins de coordinateurs, moins de rédacteurs juniors, moins de codeurs juniors faisant du travail de nettoyage, et plus de pression sur les personnes restantes pour valider la sortie machine au lieu de générer chaque ligne elles-mêmes.
On voit déjà le schéma dans le flux de travail ordinaire. Un manager avait l'habitude d'avoir besoin d'un analyste pour rassembler le matériel de base, rédiger la note interne et donner forme à la première recommandation. Maintenant, l'analyste existe peut-être encore, mais il peut probablement servir plusieurs managers à la fois. Ou bien un manager a besoin de moins d'analystes. La même chose se produit dans la revue de code. Un humain compte encore, parfois beaucoup, mais l'humain est tiré vers le haut, vers la validation, les cas limites et la responsabilité, tandis que la première passe bon marché est générée ailleurs.
Voilà pourquoi le travail de bureau est plus exposé que les gens ne veulent l'admettre. C'est parce que le travail d'information était coûteux. Les organisations devaient payer des humains pour la première passe parce qu'il n'y avait pas d'autre moyen d'en obtenir une. Une fois la première passe devenue bon marché, la valeur du poste est jugée plus sévèrement. Le poste n'est plus tarifé autour de la production de langage organisé. Il est tarifé autour de la responsabilité, de la vérification et des conséquences.
Le contraste avec l'art et les autres travaux difficiles à spécifier doit rester limité. Un bon travail visuel reste plus difficile à décrire précisément et plus difficile à vérifier à bon marché que du texte, de la logique de tableur ou des modifications de code de routine. Cela ne rend pas le travail créatif immunisé. Cela veut simplement dire que la logique de compression est la plus forte là où le succès est facile à décrire et l'échec bon marché à inspecter.
Le travail qui survit mieux se tient plus près du réel. Il possède des systèmes, valide des résultats, absorbe des conséquences et gère un contexte désordonné qui n'entre pas proprement dans une file de relecture. Il est plus difficile de compresser le travail de la personne qui doit valider un système physique, gérer un conflit client en direct, assumer la réponse à une panne, ou prendre une décision quand les données sont incomplètes et le coût de l'erreur réel. Si tant est, cela rend ces goulets d'étranglement humains restants plus visibles. Pour les ingénieurs par exemple, cela réduit beaucoup le coût d'écriture du code (et même des conceptions), tout en augmentant la valeur des gens capables de s'adapter et de mener quelque chose à son terme. Être une personne de bout en bout, quelqu'un capable de décomposer une idée ou une fonctionnalité en de nombreux composants, puis de les prioriser et de les exécuter, c'est ça l'ingénierie logicielle aujourd'hui. Il est peu probable que vous codiez beaucoup encore, surtout à mesure que l'IA s'y améliore. Mais vous devrez comprendre les motifs, les conceptions, l'outillage… et assembler tout cela.
Oui, l'IA seule ne construira rien. Mais une personne avec l'IA construira ce qu'une équipe de 10 faisait avant. Alors, à ces 9, on peut tout à fait dire que l'IA est en train de les remplacer.
Thoughts
-
Le passage sur l'art qui résisterait mieux « parce que c'est dur à spécifier », j'y crois moyen. Dur à spécifier, ça veut souvent juste dire qu'on n'a pas encore mis le truc dans la file d'attente. On disait pareil de la traduction et du graphisme. Ce take-là sent surtout le « moi ça va aller » repeint en théorie, et il survit pas à une première réponse honnête.
-
« L'IA seule ne construit rien » ouais ouais. Dis ça aux neuf qui sont remplacés. Eux autres, l'IA construit très bien leur lettre de licenciement, checke ben.
-
Question sérieuse aux optimistes : si une personne porte désormais la sortie de dix, qui valide quand cette personne se trompe ? Avant, dix paires d'yeux attrapaient une partie des erreurs. Le goulet de relecture dont parle clemence, c'est pas un détail, c'est le nouveau point de panne unique. On a optimisé le coût et fragilisé la vérification.
-
« Une personne de bout en bout qui fait le boulot de dix », tranquille. Sauf que dans ma boîte la dixième personne a pas été virée, elle a été renommée deux fois en deux réorgas et elle monte toujours en compétence sur le stack d'avant. L'IA remplace pas le poste, elle remplace le moment où quelqu'un aurait fini par remarquer que la moitié de l'orga attend le bus. Peinard.
-
« Plus de pression sur les restants pour valider la sortie machine », c'est ma semaine résumée. On a réduit l'équipe en se disant que l'outil compenserait. Résultat : je valide deux fois plus de diffs, dont la moitié sont des erreurs subtiles que le modèle pond avec une assurance parfaite. La première passe est rapide, la relecture est devenue le goulet. On a juste déplacé le travail invisible, on ne l'a pas supprimé.
-
Le « être une personne de bout en bout » est la bonne conclusion, et c'est précisément le travail qu'on a passé des années à ne pas créditer. Décomposer une feature floue, prioriser, gérer les cas que personne n'avait prévus, c'était déjà le vrai métier avant l'IA. Sauf qu'avant on appelait ça « juste du front » et on le payait comme de la déco.
-
Une précision : « vérifier moins cher que produire » n'est vrai que quand l'échec est lisible. Sur du code de routine avec critères clairs, oui. Sur un bug de concurrence ou une régression de perf, vérifier la sortie machine coûte parfois plus cher que l'avoir écrite soi-même, parce qu'il faut d'abord deviner ce que le modèle croyait faire. L'article généralise un cas favorable.
-
Côté produit je le vois déjà sur les decks. Avant, un analyste passait deux jours à rassembler le matériel de base avant qu'on mette en forme la reco pour la direction. Là, la première passe sort en une matinée, faque ce qui reste c'est de vérifier que les chiffres tiennent et d'assumer la slide en réunion. Le poste a pas disparu, mais on en garde un pour trois managers au lieu d'un par manager. Pis personne le dit clairement en revue, c'est ça qui est bizarre.
-
Le déplacement « du langage organisé vers la responsabilité » est juste, et il est déjà visible en revue de code. Avant je relisais le code de trois juniors. Maintenant je relis trois PR sorties d'un modèle, et le boulot a changé de nature : moins de « ça compile », plus de « qui répond si ça pète à 2h ». La première passe est gratuite, la responsabilité ne l'est toujours pas, et c'est elle qu'on paie désormais.
-
Attention au passage « l'art résiste mieux parce que c'est dur à spécifier ». C'est exactement ce qu'on disait du front il y a cinq ans, et regarde où on en est. Le travail dur à vérifier n'est pas protégé, il est juste pas encore arrivé dans la file de relecture. Le frontend, c'est là où l'ambiguïté produit devient cliquable, et un modèle ne sait toujours pas ce qu'un vrai utilisateur va casser. Ça, ça tient encore. Le reste, j'en suis moins sûre que l'article.