Construire pour durer

Il y a quelques jours, j'écoutais une conversation entre Jeremy Howard (fast.ai) et Chris Lattner — le créateur de LLVM, Swift, et Mojo. Une heure de discussion posée, sans slides, sans hype. Juste deux ingénieurs qui refusent de céder à la panique ambiante.

J'ai tout écouté d'une traite. Rare.

Parce que ce que Lattner dit là, ça m'a touché directement. Pas comme une conférence lointaine sur "l'avenir du dev". Comme un miroir tendu sur 18 ans de décisions de conception, de refactorings, d'apps maintenues, abandonnées, ou réécrites from scratch.

La question centrale qu'ils posent est simple, presque banale.

Comment est-ce qu'on construit un système qui dure plus de six mois ?

La réponse, elle, en revanche, est tout sauf simple.

LLVM : le compilateur que personne n'avait demandé

Noël 2000. Chris Lattner, doctorant, commence à écrire LLVM dans son coin. Pas pour résoudre un problème précis. Pas pour répondre à un appel d'offres. Pour répondre à une question fondamentale : qu'est-ce qu'une infrastructure de compilateur devraitêtre, à la base ?

Vingt-cinq ans plus tard, LLVM est partout. Rust, Swift, Julia — des langages entiers ont été construits dessus. Clang, le compilateur C/C++/Objective-C créé par Lattner lui-même, en est le frontend officiel — c'est lui qui tourne dans Xcode depuis 2013, derrière chaque build de chaque app iOS.

Ce n'est pas de la chance. C'est de l'architecture.

Et pour comprendre pourquoi ça tient aussi bien, il faut saisir un truc clé dans la conception de LLVM : la représentation intermédiaire, ouLLVM-IR.

L'idée est élégante. Au lieu de compiler directement du C++ (ou du Swift, ou du Rust) vers du code machine — ce qui oblige à tout réécrire pour chaque processeur, chaque architecture — LLVM introduit une étape intermédiaire universelle. Tous les langages se traduisent d'abord en LLVM-IR. Ensuite, LLVM transforme ce IR en code machine optimisé pour la cible : un iPhone, un Mac Apple Silicon, un serveur Linux.

C'est comme un traducteur pivot. Tu parles français, anglais, espagnol — peu importe. Tout passe d'abord par l'esperanto, et c'est depuis là qu'on traduit vers la destination finale.

Ce pipeline en trois temps — source → IR → code machine — c'est ce qui a permis à Rust d'exister sans réécrire un compilateur complet, à Swift de tourner sur iPhone dès le premier jour, et à Xcode d'utiliser LLVM en production depuis des années. On greffe un nouveau langage en amont, on greffe un nouveau processeur en aval. Le cœur, lui, ne bouge pas.

C'est ça, first principles. Pas une solution pour aujourd'hui. Une fondation pour des langages qui n'ont pas encore été inventés.

"Les systèmes qui s'effondrent sous leur propre poids le font parce que leur architecture était défaillante dès le départ. Ceux qui durent, c'est parce que quelqu'un a pris le temps de comprendre ce qu'il construisait — et pourquoi." — Chris Lattner

Ce mindset, je le reconnais. C'est exactement ce qui sépare une app iOS qui tient deux ans d'une app qu'on réécrit from scratch au bout de six mois. Ce n'est pas la qualité du code au sens syntaxique. C'est la qualité de la réflexion qui a précédé ce code.

L'architecture, c'est ce qu'on ne voit pas — mais ce qui décide de tout.

Le vibe coding : symptôme d'une époque

Aujourd'hui, l'injonction est claire : shippe vite, shippe souvent, utilise l'IA pour aller 10x plus vite. Des CEOs se vantent publiquement que leurs équipes génèrent 10 000 lignes de code par jour grâce aux agents.

10 000 lignes par jour.

Lattner a un mot pour ça : un metric inutile. Voire dangereux.

"Je ne suis pas un CEO qui se vante du nombre de lignes générées par l'IA. Je considère ça comme un passif, pas un atout. Ce qui compte, c'est : est-ce que le produit s'améliore ? Est-ce que les gens comprennent ce qu'ils construisent ?"

Le vibe coding — lancer une boucle agentique et espérer que quelque chose d'utile en sorte — c'est du jeu de hasard déguisé en productivité. Howard l'a dit exactement comme ça : "C'est comme tirer la manette d'une slot machine. Tu perds, tu retires. Tu perds, tu retires."

L'histoire qui m'a glacé

Lattner raconte un cas concret. Un senior engineer, bug reporté, agentic loop lancé, PR générée. La PR passait les tests. Le bug "disparaissait".

Sauf que non. Le symptôme était masqué. Sous la surface, le codebase venait d'absorber une bombe à retardement : du code au mauvais endroit, qui faisait la mauvaise chose, qui allait créer trois nouveaux bugs plus subtils que le premier.

Le code avait été mergé sans que personne ne comprenne vraiment ce qu'il faisait.

Ce n'est pas un problème d'outil. C'est un problème de culture. Une culture qui a appris à faire disparaître les symptômes plutôt qu'à comprendre les causes.

Ce que ça change pour un ingénieur / développeur iOS

Je construis des apps iOS depuis 2008, et pour d'autres plateformes (PalmOne, Casio, ... depuis avant...). Des paradigmes, langages, trends, j'en ai vu passer : CasioVB, Java, Objective-C, ARC, Swift, SwiftUI, les différentes architectures MVC/MVVM/TCA. J'ai réécrit des apps entières. J'en ai maintenu d'autres pendant des années.

Et je peux vous dire une chose : la dette technique ne dort jamais.

Elle attend. Elle s'accumule. Et elle se réveille au pire moment — quand vous avez une deadline, quand Apple sort une nouvelle version d'iOS, quand un utilisateur remonte un bug que vous ne comprenez plus parce que la personne qui a écrit ce code n'est plus là. Ou c'était vous, il y a trois ans, et vous ne vous souvenez plus du raisonnement.

L'IA n'a pas changé cette réalité. Elle l'a accélérée.

Avec Onyria - ma dernière app -, j'ai fait un choix conscient : utiliser l'IA comme accélérateur, pas comme architecte. Les décisions de structure — comment gérer les crédits utilisateur, comment orchestrer les appels à l'API Reve, comment synchroniser les données entre devices via SwiftData sans serveur externe — ces décisions, c'est moi qui les prends. L'IA peut m'aider à écrire le boilerplate, à explorer des alternatives, à repérer des edge cases. Mais elle ne peut pas comprendre les contraintes d'un écosystème Apple à ma place.

Ça, c'est 18 ans d'expérience qui parlent. Et ça ne s'automatise pas.

La bifurcation

Howard pose un excellent diagnostic :

"Il va y avoir deux groupes. Ceux qui ont développé une learned helplessness — qui ne savent plus vraiment ce qu'ils font sans l'IA. Et ce groupe plus petit dont tout le monde se demandera : 'Comment il sait tout ça ? Il est incroyable.'"

On le voit déjà. Les délais de review App Store s'allongent parce que le volume de soumissions explose — mais pas la qualité. Apple resserre ses guidelines (4.1, 4.2, 4.3) contre les apps clonées générées par prompt. La barre monte.

Pour les développeurs qui comprennent ce qu'ils font, c'est une bonne nouvelle. L'écosystème se nettoie. La compétence redevient un avantage compétitif réel — pas juste théorique.

La question que Lattner pose à chaque ingénieur est directe :

"Quand la hype se stabilise — et elle se stabilise toujours — où tu en es, toi ? Tu as progressé ? Ou tu as passé deux ans à tirer des levier en espérant que l'IA te rende meilleur par osmose ?"

Comment j'utilise l'IA, concrètement

Lattner utilise l'IA. Il parle d'un gain de 10 à 20 %. Mais il maintient ce qu'il appelle une tight iteration loop : edit, compile, run, debug. À chaque instant, il sait ce que son code fait.

C'est exactement mon approche.

L'IA m'aide à :

• Explorer une API que je ne connais pas encore
• Générer du boilerplate que je n'ai pas envie d'écrire à la main
• Challenger mon architecture avant de la committer
• Repérer des cas limites que j'aurais pu manquer

Ce qu'elle ne fait pas à ma place :

• Décider de l'architecture
• Comprendre les contraintes métier
• Maintenir la cohérence sur la durée
• Valider que ce qui sort a du sens dans le contexte global

La différence entre les deux, c'est la différence entre un outil et une béquille. Un outil amplifie ce que tu sais faire. Une béquille compense ce que tu ne sais pas faire — et t'empêche d'apprendre.

Ce que je retiens

L'interview de Lattner n'est pas un manifeste anti-IA. C'est un rappel que les fondamentaux ne sont pas périmés.

Architecture. Compréhension. Artisanat.

Ce sont les mêmes principes qui ont permis à LLVM de tourner 25 ans après sa création. Les mêmes qui font qu'une app iOS bien conçue se maintient, évolue, et résiste aux changements de plateforme.

L'IA est un outil formidable. Mais les outils n'ont jamais remplacé le jugement.

Et le jugement, ça se construit dans les tranchées — dans les bugs qu'on a passé trois jours à comprendre, dans les refactorings douloureux qu'on a menés jusqu'au bout, dans les décisions d'architecture qu'on a assumées sur la durée.

Ce n'est pas ce que l'IA génère qui définit votre valeur en tant que développeur. C'est ce que vous comprenez de ce qu'elle génère.

L'interview complète est disponible surfast.ai. Je vous met la video (en anglais) ici :