Plus payé pour taper du code : une journée de travail à l'IA dans une entreprise cloud

Cette interview en français d'Underscore_ s'ouvre sur une étude affirmant que l'IA n'a jamais touché à la productivité bureautique, puis présente le tableau inverse : les équipes utilisant intensivement des assistants de code se seraient métamorphosées depuis fin 2025. L'invité est Quentin Adam, dirigeant de Clever Cloud, un fournisseur cloud français fort de plus de 15 ans d'histoire. Le décor : une société de 70 développeurs qui construit chaque couche du logiciel cloud, y compris sa propre base de données, une cuisine où la tolérance à l'erreur est proche de zéro.

La première impression d'Adam était loin de l'enthousiasme actuel : il décrit ouvertement les premiers modèles comme des perroquets statistiques qu'il ne pouvait pas prendre au sérieux parce qu'ils produisaient du code qui ne compilait pas. Le tournant est venu des architectures d'agents construites autour de boucles de rétroaction ; modèle plus compilateur plus résultats de tests travaillant ensemble ont commencé à battre son propre code. Il y a environ 18 mois, un essai où la machine a écrit une meilleure solution plus vite que lui a changé son avis.

L'une des affirmations les plus contre-intuitives concerne le choix du langage : au lieu de JavaScript et Python, qui disposent des plus grands corpus d'entraînement, Rust avec son compilateur strict est recommandé. La logique est simple : dans les langages faiblement compilés, le mauvais code passe silencieusement et explose à l'exécution, tandis qu'en Rust le compilateur râle bruyamment et le modèle peut le comprendre et le corriger. L'histoire assez uniforme de Rust, sans changements cassants, garde aussi les données d'entraînement plus cohérentes. Des builds expérimentaux rapides sont conseillés de bout en bout en Rust.

L'histoire de l'adoption en entreprise est un cas d'école : les annonces à l'échelle de la société n'ont ému personne et la résistance était forte. Adam s'est assis à côté des ingénieurs un par un pour des essais conjoints ; la glace s'est brisée quand un ingénieur a vu cinq semaines de son travail réécrites en mieux en deux heures. Un mandat descendant d'outil unique a échoué aussi ; à la place, les ingénieurs ont obtenu la liberté de se faire rembourser l'outil de leur choix, avec interdiction des plans annuels car les outils périment en moins d'un an.

Que les adaptateurs les plus rapides soient des ingénieurs seniors est une découverte surprenante : des responsables qui n'avaient jamais le temps de coder à côté de la gestion de leurs équipes se sont remis à coder avec des assistants, certains disant qu'ils produisent maintenant le code le plus propre de leur vie. Écrire directement un brouillon fonctionnel bat la rédaction de documents de spécification et les réunions pour formaliser les idées. Les bonnes pratiques autrefois sacrifiées faute de temps sont redevenues abordables.

La rupture philosophique apparaît ici : le développeur qui fait écrire le code par la machine devient testeur, un rôle que personne ne trouve valorisant. La solution a été de forcer la machine à écrire les tests : des couches unitaires, d'intégration et de simulation construites pas à pas. Les services simulés et les harnais élaborés autrefois écartés comme trop coûteux sont devenus la norme une fois la génération devenue bon marché. Une approche de simulation dérivée de FoundationDB valide désormais chaque changement automatiquement.

Côté sécurité, chaque changement entrant affronte des tests d'intrusion automatisés, en partant du principe qu'une faille qu'un modèle ne trouve pas a peu de chances d'être trouvée par le modèle d'un attaquant, plusieurs modèles se relayant pour attaquer leur propre infrastructure. Cela a débusqué des failles dormantes depuis longtemps que personne n'avait jamais exploitées. L'objectif 2026 est audacieux : ne faire tourner que du code de millésime 2026 dans toute l'entreprise et retirer 15 ans d'héritage. Comme les décisions d'architecture restent en interne, cela est présenté comme une réécriture dont on peut être fier.

Confier à l'IA des corvées inhumaines est le passage le plus original de l'interview : pour un monolithe touché par 30 personnes, les branches, résultats de tests, commentaires, mails et journaux de discussion sont donnés à la machine pour signaler les points de tension avant la réunion hebdomadaire de synchronisation. Une tâche de documentation coûtant à un humain trois ou quatre jours prend vingt minutes à la machine. Les zones de code redoutées que personne ne touche et les migrations de bibliothèques relèvent de la même catégorie ; faire réimplémenter une bibliothèque pendant la nuit avec un audit de performances au réveil est désormais monnaie courante.

Les limites sont énoncées franchement : à la pointe de la recherche, où il n'existe presque pas de code public, comme les noyaux et les systèmes d'exploitation de commutateurs, les gains restent proches de 1,5x et le modèle peut même gêner. Les brouillons et les preuves de concept, en revanche, voient des accélérations allant jusqu'à un facteur dix. Les entreprises qui rapportent de mauvais résultats partagent une même erreur : générer du code sans construire autour le harnais de qualité et de sécurité, produisant un code inintelligible avec un modèle inintelligible en espérant que les tests rattrapent le coup après coup.

La conclusion se raccroche à la souveraineté numérique européenne : l'effondrement des coûts logiciels offre une chance de reproduire à bas prix d'anciennes dépendances, et la distillation de modèles permettrait aux Européens de rester derrière les modèles américains sans jamais être très loin. L'appel à projets de 180 millions d'euros pour un cloud souverain des institutions européennes, remporté par un consortium incluant OVH et Clever Cloud, est présenté comme preuve. La clause de souveraineté d'Adam dans les grands contrats, accordant aux clients une licence illimitée si l'entreprise change de mains sous droit étranger, est présentée comme une garantie radicale.