---
title: Deux trimestres pour arrêter d’écrire du code à la main
description: Le cofondateur de Datadog a annoncé à toute l’équipe d’ingénierie que d’ici deux trimestres, plus personne n’écrirait de code à la main. Ce que le PDG Olivier Pomel dit de cette échéance, pourquoi Datadog ne fait pas de « token maxing », et ce que cela change pour les développeurs.
date: 2026-11-06
tags: agents IA, agents de code, avenir du travail, développeurs, tokenmaxxing
---

« Dans deux trimestres, on n’écrit plus de code. » C’est ce que le cofondateur de Datadog a dit à toute l’équipe d’ingénierie, raconte son PDG, Olivier Pomel. Ce n’est pas une interdiction du code. C’est le métier qui s’inverse : les ingénieurs écrivaient surtout du code et automatisaient parfois. Désormais, ils vont surtout automatiser et parfois écrire.

Datadog n’est pas un labo d’IA à la puissance de calcul illimitée. C’est une entreprise cotée d’environ 8 000 personnes, qui vend de l’observabilité : les outils qui montrent ce qui se passe à l’intérieur d’un logiciel en production. Quand une entreprise comme celle-là fixe une date de fin au code écrit à la main, toutes les équipes qui écrivent du logiciel se posent la même question. Quel est le métier d’un développeur quand taper le code n’en est plus l’essentiel ?

Il l’a dit dans une [interview de Y Combinator](https://www.youtube.com/watch?v=vb1Gcn10enw) publiée en juillet, en anglais. L’essentiel des 30 minutes raconte l’histoire de Datadog. La partie sur l’IA et le code dure environ sept minutes, et cette note parle de ces sept minutes.

## La plupart des entreprises ne brûleront pas un milliard

La question sur le code est arrivée juste après qu’il a parlé des labos d’IA. Datadog compte parmi ses clients les dix plus grandes entreprises d’IA, beaucoup de startups d’IA et de grandes entreprises comme des banques ou des compagnies ferroviaires. Les deux ou trois plus grands labos utilisent son produit « de façon bizarre », dit-il. Selon ses mots, ils ont un calcul infini, une inférence infinie et des modèles que personne d’autre n’a encore.

Les labos ne montrent donc pas ce que tout le monde fera. La plupart des entreprises, dit-il, ne seront pas ravies d’« incinérer un milliard en calcul » pour du travail interne.

Puis l’intervieweur a demandé : « Est-ce que vous faites du token maxing ? » Le token maxing, c’est dépenser autant de tokens que possible sur chaque tâche où plus de travail donne un meilleur résultat. Les tokens sont les unités que les modèles d’IA facturent. J’ai parlé de ce mot dans [une note précédente](/fr/notes/tokenmaxxing-fat-skills-real-tests.html). Sa réponse a été courte : « On ne fait pas de token maxing. »

Datadog met plutôt l’intelligence dans son propre produit. Lancer un agent de code généraliste comme Claude Code sur un problème d’exploitation, dit-il, c’est un peu comme acheter un billet en classe affaires pour envoyer une carte postale. Datadog place donc ce travail dans le produit, à côté des données qu’il surveille, pour que le système fasse le travail seul. L’entreprise rend aussi son produit facile à utiliser pour les agents, parce que ses clients y branchent déjà les leurs.

<figure class="fd-fig kf" aria-labelledby="tq1-cap" data-desc="Deux cartes. À gauche, les plus grands labos d’IA : du calcul sans limite, selon ses mots une inférence infinie, des modèles que personne d’autre n’a encore, et pas ce que fera le reste du monde. À droite, en bleu, Datadog : pas de token maxing ; l’intelligence intégrée au produit, pour que le système agisse seul, et un produit facile à utiliser pour les agents des clients. Sous les cartes : et pourtant, une date de fin pour le code écrit à la main.">
<p class="kf-kick">Deux façons de dépenser pour l’IA</p>
<p class="kf-title">Les labos peuvent brûler un milliard, <em>la plupart des entreprises, non</em></p>
<div class="kf-cards">
<div><small>Les plus grands labos d’IA</small><b>Du calcul sans limite</b><ul><li>Une inférence infinie, selon ses mots</li><li>Des modèles que personne d’autre n’a encore</li><li>Pas ce que fera le reste du monde</li></ul></div>
<div class="is-key"><small>Datadog</small><b>Pas de token maxing</b><ul><li>L’intelligence intégrée au produit</li><li>Pour que le système agisse seul</li><li>Facile à utiliser pour les agents des clients</li></ul></div>
</div>
<p class="kf-note">Et pourtant : une date de fin pour le code écrit à la main.</p>
<figcaption id="tq1-cap">Sa description de ses clients et de son entreprise. « Infini » est son mot, pas une mesure.</figcaption>
</figure>

## Surtout automatiser, parfois écrire

L’échéance est venue dans la même réponse. Quelques mois avant l’interview, son cofondateur et CTO, Alexis Lê-Quôc, s’est présenté devant toute l’équipe d’ingénierie. Dans deux trimestres, leur a-t-il dit, plus personne n’écrirait de code.

L’intervieweur a vérifié : la règle, c’est donc plus de code du tout ? Pas tout à fait. « En réalité, on écrira du code, on réécrira du code », dit Olivier. L’idée est une inversion : « Avant, vous écriviez surtout, et vous automatisiez parfois. Maintenant, vous allez surtout automatiser, et parfois écrire. »

Il ne décrit pas à quoi ressemble l’automatisation au quotidien. Ma lecture : un agent écrit la plupart des premières versions. L’ingénieur décide quoi construire, vérifie ce qui revient et reprend la main là où l’agent n’y arrive pas.

Il explique aussi pourquoi l’échéance est courte et les détails flous. La façon d’écrire du code, « ou de ne pas en écrire », a changé trois fois en un an, dit-il. Personne n’aurait pu le prévoir un an à l’avance. L’entreprise doit donc réagir vite et essayer beaucoup de choses à la fois.

<figure class="fd-fig kf" aria-labelledby="tq2-cap" data-desc="L’inversion, en deux colonnes. Avant : surtout écrire du code, parfois automatiser. Dans deux trimestres, en bleu : surtout automatiser, parfois écrire du code. Sous le tableau : pas une interdiction, on écrit et on réécrit encore du code.">
<p class="kf-kick">La consigne, dans ses mots</p>
<p class="kf-title">Écrire et automatiser <em>échangent leur place</em></p>
<div class="kf-swap">
<p class="kf-swap-h"><span>Avant</span><span>Dans deux trimestres</span></p>
<p><span>Surtout écrire du code</span><em>Surtout automatiser</em></p>
<p><span>Parfois automatiser</span><em>Parfois écrire du code</em></p>
</div>
<p class="kf-note">Pas une interdiction : on écrit et on réécrit encore du code.</p>
<figcaption id="tq2-cap">Ses mots, tirés de l’interview. L’échéance est mon estimation : deux trimestres après une consigne donnée quelques mois avant juillet.</figcaption>
</figure>

## Une personne, quelques jours

L’échéance vient de ce que les gens ont vu, pas d’une prévision. Comme beaucoup d’entreprises, Datadog a eu un déclic en décembre. Il donne deux raisons. Les modèles sont devenus assez bons : « le seuil a été franchi ». Et c’étaient les vacances, donc les gens avaient du temps pour un projet à eux.

Le résultat l’a convaincu. Des « développeurs absolument excellents, pas des débutants » ont reconstruit seuls des systèmes entiers, en quelques jours. Il estime le même travail à une équipe de six pendant six mois, à l’ancienne.

Cela a suffi pour changer la façon dont toute l’entreprise travaille. « Ça va être douloureux. C’est douloureux, mais on le fait. »

<figure class="fd-fig kf" aria-labelledby="tq3-cap" data-desc="Deux cartes. À gauche, en pointillé, l’ancienne estimation : six personnes pendant six mois, ce qu’une telle refonte aurait demandé avant. À droite, en bleu, pendant les vacances de décembre : une personne en quelques jours, des développeurs excellents, pas des débutants, chacun seul. Sous les cartes : cela a convaincu les fondateurs de changer toute l’organisation.">
<p class="kf-kick">Reconstruire un système entier</p>
<p class="kf-title">Six personnes pendant six mois, <em>ou une seule en quelques jours</em></p>
<div class="kf-cards">
<div class="is-dim"><small>L’ancienne estimation</small><b>6 personnes, 6 mois</b><span>Ce qu’une telle refonte aurait demandé avant.</span></div>
<div class="is-key"><small>Pendant les vacances de décembre</small><b>1 personne, quelques jours</b><span>Des développeurs excellents, pas des débutants, chacun seul.</span></div>
</div>
<p class="kf-note">Cela a convaincu les fondateurs de changer toute l’organisation.</p>
<figcaption id="tq3-cap">Son estimation. Il ne nomme aucun projet et ne montre aucune mesure.</figcaption>
</figure>

## Des équipes de deux ou trois

Le premier changement qu’il voit, c’est la taille des équipes. Pour explorer une idée, il fallait une équipe de huit. Maintenant, deux ou trois personnes suffisent.

Cela colle à sa règle pour cette période : l’IA va trop vite pour attendre que les clients demandent quelque chose. Il faut donc tenter plus de coups, et accepter de se tromper plus souvent. Une équipe plus petite rend chaque échec moins cher.

Tout le reste est ouvert. « Ça change tout, dit-il, mais le plus délicat, c’est qu’on ne sait pas encore à quoi ressemble la destination. » Personne ne sait quel sera le processus dans un an. Personne ne sait combien de product managers, de designers, de spécialistes sécurité ou d’ingénieurs il faut pour construire un produit.

Alors, qui seront les ingénieurs de ces petites équipes ?

<figure class="fd-fig kf" aria-labelledby="tq4-cap" data-desc="Personnes nécessaires pour explorer une idée, en deux barres. Avant : une équipe de huit. Maintenant, en bleu : deux ou trois personnes, une barre qui rétrécit dans le contour en pointillé de l’ancienne équipe. Sous les barres, ce que personne ne sait encore : combien de product managers, de designers, de spécialistes sécurité et d’ingénieurs il faut pour un produit.">
<p class="kf-kick">Personnes nécessaires pour explorer une idée</p>
<p class="kf-title">D’une équipe de huit à <em>deux ou trois personnes</em></p>
<div class="kf-bars">
<p class="kf-bar"><span>Avant</span><span class="kf-track"><i style="--v:100"></i></span><b data-count="8">8</b></p>
<p class="kf-bar is-key"><span>Maintenant</span><span class="kf-track"><i class="kf-ghost" style="--v:100"></i><i style="--v:31;--from:100"></i></span><b>2 ou 3</b></p>
</div>
<p class="kf-note">Encore inconnu : combien de PM, de designers, de spécialistes sécurité et d’ingénieurs il faut pour un produit.</p>
<figcaption id="tq4-cap">Son exemple, pas une équipe mesurée. La barre de deux ou trois est tracée à deux et demi.</figcaption>
</figure>

## Les petites tâches servaient de formation

Il ne parle pas des juniors. Mais regardez qui a fait les refontes de décembre : des développeurs excellents, pas des débutants. Les gros gains sont venus de gens qui savent déjà à quoi ressemble un bon système.

Ce savoir a une histoire. Les juniors apprenaient sur de petites tâches : un changement de config, un premier test, une correction dans un README. Une partie de ce travail ratait, et c’est comme ça que le jugement se formait. Les agents de code peuvent maintenant prendre ces tâches.

Les données d’embauche vont déjà dans ce sens. Une équipe de Stanford suit les données de paie américaines. Dans les métiers exposés à l’IA, comme le développement logiciel, l’emploi des 22-25 ans était 19 % en dessous de son niveau attendu en juin 2026. Les salariés expérimentés des mêmes métiers ne montrent pas cet écart. J’ai détaillé cette étude dans [l’abondance de l’intelligence](/fr/notes/abundance-of-intelligence.html).

Une réponse s’appelle [PRAISE](/fr/notes/preceptors-ship-seniors.html), un programme de Microsoft et de Carnegie Mellon. Il associe chaque nouvel ingénieur à un senior dont le travail est de « livrer des seniors ». Quand une équipe automatise surtout, les petites tâches cessent d’enseigner le jugement par accident. Quelqu’un doit l’enseigner exprès.

<figure class="fd-fig kf" aria-labelledby="tq5-cap" data-desc="Comment un junior devenait senior, en trois étapes. Un, en rouge, les petites tâches : un changement de config, un premier test, un README corrigé, les tâches que les agents de code prennent maintenant. Deux, les erreurs : une partie de ce travail rate, et vous apprenez pourquoi. Trois, le jugement : vous savez à quoi ressemble un bon système. Sous les étapes : les refontes de décembre demandaient ce jugement, puisqu’elles étaient faites par des développeurs excellents, pas des débutants.">
<p class="kf-kick">Comment les juniors devenaient seniors</p>
<p class="kf-title">Le jugement venait <em class="is-alert">des tâches que prennent les agents</em></p>
<ol class="kf-steps">
<li class="is-alert"><b>Petites tâches</b><span>Un changement de config, un premier test, un README corrigé. Les agents les prennent maintenant.</span></li>
<li><b>Erreurs</b><span>Une partie de ce travail rate, et vous apprenez pourquoi.</span></li>
<li><b>Jugement</b><span>Vous savez à quoi ressemble un bon système.</span></li>
</ol>
<p class="kf-note">Les refontes de décembre demandaient ce jugement : des développeurs excellents, pas des débutants.</p>
<figcaption id="tq5-cap">Ce chemin vient d’une note précédente de ce site, pas de l’interview.</figcaption>
</figure>

## À essayer

La partie sur l’IA commence vers la 19e minute de l’interview, et la question sur le token maxing arrive juste avant la 24e.

- Y Combinator, [What Top AI Labs Are Really Doing With Observability](https://www.youtube.com/watch?v=vb1Gcn10enw), avec Olivier Pomel, juillet 2026, en anglais.
- [Dépenser plus de tokens ne paie qu’avec de bons skills et de vrais tests](/fr/notes/tokenmaxxing-fat-skills-real-tests.html), sur le mot token maxing.
- [L’usine logicielle agentique, c’est celle de 2022 avec une seule case changée](/fr/notes/software-factory-2022-to-lights-off.html), sur la relecture qui devient l’étape lente quand construire va vite.
- [L’abondance de l’intelligence](/fr/notes/abundance-of-intelligence.html), pour les données d’embauche des jeunes.
- [Le travail d’un précepteur, c’est de livrer des seniors](/fr/notes/preceptors-ship-seniors.html), sur la façon dont les juniors deviennent quand même seniors.

Essayez ensuite son inversion sur une semaine de votre propre travail. Comptez les heures passées à écrire du code, et celles passées à décider, vérifier et corriger ce qu’un outil a écrit. Si vous essayez, dites-moi quel côté pesait le plus.