Dans son manifeste consacré à l'intelligence artificielle, Bart Butler, CTO de Proton, lance « Programming is dead », une affirmation volontairement provocatrice.
Selon lui, l'écriture manuelle du code perd progressivement son intérêt. Les développeurs doivent désormais apprendre à piloter des agents d'intelligence artificielle, repenser leurs méthodes de travail et devenir les architectes de systèmes capables de produire du logiciel de manière autonome. Son constat est pertinent, mais sa conclusion me semble prématurée.
Oui, l'IA transforme profondément le développement logiciel. Génération de code, documentation, tests, débogage etc... De nombreuses tâches peuvent désormais être automatisées. Continuer à travailler comme si ces outils n'existaient pas serait une erreur. Mais confondre la production de code avec l'ingénierie logicielle est une simplification dangereuse.
Car programmer ne consiste pas uniquement à écrire des instructions. C'est comprendre un problème, définir une architecture, anticiper les interactions entre composants, évaluer les risques et garantir la fiabilité d'un système. L'IA automatise une partie de l'exécution, pas nécessairement la réflexion qui la précède.
La programmation ne meurt pas, elle change de niveau d'abstraction.
La productivité de l'IA, une réalité moins évidente qu'il n'y paraît
Butler défend l'idée que l'IA permet aux développeurs de produire davantage en moins de temps. Les études confirment en partie cette affirmation, mais révèlent une situation beaucoup plus contrastée. L'une d'elles, publiée en 2026 dans Management Science et menée auprès de 4867 développeurs dans trois entreprises, observe une augmentation moyenne de 26,08% du nombre de tâches réalisées avec l'assistance de l'IA.
Mais une expérience de METR publiée en 2025 aboutit à une conclusion opposée. Sur 246 tâches confiées à 16 développeurs expérimentés travaillant sur leurs propres projets open source, l'utilisation de l'IA a augmenté le temps nécessaire à leur réalisation de 19%. Le rapport DORA de Google Cloud apporte une autre nuance. Il relève une association entre l'adoption de l'IA et une amélioration de la productivité individuelle, mais aussi une dégradation du débit de livraison et de la stabilité des changements.
Ces résultats ne sont pas contradictoires, ils mesurent des contextes différents. Ils montrent surtout que l'IA n'est pas automatiquement synonyme de productivité. Produire davantage de code ne veut pas forcément dire fabriquer de meilleurs logiciels. Si la génération s'accélère, mais que les tests, les revues et les validations ne suivent pas, nous ne faisons que déplacer les goulots d'étranglement.
Le développeur ne doit pas devenir un simple superviseur d'agents
Je partage l'idée de Bart Butler selon laquelle le métier évolue vers davantage de conception et de supervision. En revanche, je suis beaucoup plus réservé sur la perspective d'un ingénieur qui deviendrait essentiellement un manager d'agents. Un modèle n'est pas un développeur junior. Il peut produire une solution convaincante tout en introduisant des erreurs, des vulnérabilités ou des incohérences architecturales.
C'est particulièrement problématique dans des domaines comme la sécurité, la cryptographie et la protection des données, où une erreur peut avoir des conséquences considérables. L'expertise humaine ne doit donc pas devenir secondaire. Elle est précisément ce qui permet de contrôler les résultats de l'automatisation.
Il existe également un risque à long terme. Si les jeunes développeurs délèguent de façon systématique les tâches avancées à l'IA, comment acquerront-ils l'expérience nécessaire pour en vérifier les résultats ? Nous pourrions créer une industrie de plus en plus dépendante de systèmes que ses propres ingénieurs comprennent de moins en moins.
Le véritable enjeu est organisationnel
Sur un point, Butler a parfaitement raison. Adopter des assistants de programmation ne suffit pas. Les entreprises doivent repenser leurs processus, leurs outils et leurs méthodes de collaboration. Mais l'IA ne résout pas les problèmes d'organisation. Une équipe désorganisée qui produit du code deux fois plus vite risque simplement de générer deux fois plus de dette technique. La vraie question n'est donc pas de savoir combien d'agents une entreprise peut déployer, mais si elle est capable de produire des logiciels plus fiables, plus maintenables et réellement utiles.
La programmation n'est pas morte, celle sans réflexion peut-être
Le manifeste de Proton a le mérite de rappeler que le développement logiciel traverse une transformation d'envergure. Mais annoncer la mort de la programmation revient à confondre l'évolution d'un métier avec la disparition de ses fondements. L'avenir n'appartiendra pas nécessairement aux développeurs qui délégueront le plus de tâches à l'IA. Il sera à ceux qui sauront combiner automatisation, expertise technique et esprit critique.
Je préfère donc retourner la formule de Butler par Programming is not dead. Mindless programming is.