Introduction
Pendant sept ans, Scarf a exploité Haskell au cœur de son infrastructure de production. Pas comme un projet exploratoire, mais comme le moteur d'une plateforme d'analytique open source soumise à des exigences contractuelles d'uptime. Ce choix était assumé, documenté, défendu par un fondateur lui-même membre du conseil de la Haskell Foundation. Et pourtant, en juillet 2026, l'entreprise annonce sa migration progressive vers Python. La raison principale n'est ni un manque de fiabilité, ni une dette technique accumulée, ni une pénurie de compétences. C'est le temps de compilation.
Le compilateur, nouveau goulot d'étranglement
L'argument d'Avi Press, fondateur de Scarf, est économique autant que technique. Dans un workflow de développement augmenté par des agents IA, le cycle de build change de nature.
La logique est la suivante : un agent de codage peut produire une implémentation en quelques minutes. Si le cycle de build froid qui suit prend un quart d'heure, le compilateur est devenu le vrai frein — pas le développeur, pas la complexité du problème. Et lorsqu'on travaille avec plusieurs agents en parallèle, sur des worktrees multiples et des branches exploratoires jetables, ce coût ne se produit pas une fois : il se multiplie à chaque instance.
Hier, la boucle de feedback comportait deux étapes principales : la compilation et le runtime. Aujourd'hui, la génération de code par un modèle constitue une troisième étape, en amont, rapide et bon marché. Cette asymétrie requalifie le compilateur : là où il représentait une friction acceptable dans un workflow individuel, il peut devenir structurellement incompatible avec les cadences d'itération parallèles que les agents rendent possibles.
Une migration méthodique, sans rupture brutale
Ce que la décision de Scarf illustre surtout, c'est qu'une migration de stack peut être conduite avec méthode plutôt qu'en urgence. La stratégie retenue est progressive : développer les nouvelles routes API en Python, déployer ce serveur en parallèle du serveur Haskell existant, et migrer les fonctionnalités au fil des modifications. Le code Haskell continue de tourner en production. Les nouveaux développements se font en Python.
Le portage du code existant, facilité en partie par les LLMs eux-mêmes, ne s'est pas accompagné d'une dégradation de la qualité. La couverture de tests est décrite comme meilleure qu'elle ne l'a jamais été. Des correctifs urgents peuvent désormais être déployés en production dans le temps d'un appel client — une métrique concrète que peu d'équipes ignorent.
Ce que cela change pour les équipes techniques
Le cas Scarf n'est pas un procès en sorcellerie contre les langages compilés ni un plaidoyer pour Python. C'est une illustration claire d'une réalité que les équipes tech vont devoir intégrer dans leurs décisions d'architecture : les critères de sélection technologique évoluent avec les pratiques de développement.
Pendant des décennies, évaluer un langage revenait à peser son expressivité, ses performances à l'exécution, la richesse de son écosystème et la disponibilité des talents. Ces critères restent pertinents. Mais un paramètre supplémentaire s'impose à mesure que les workflows augmentés par des agents se généralisent : la compatibilité avec des cycles d'itération courts, parallèles et partiellement automatisés.
Un outil qui résiste à ce rythme — par ses temps de build, ses frictions d'onboarding, ou l'absence d'exemples utilisables par les agents — se retrouve structurellement désavantagé, indépendamment de ses qualités intrinsèques. Haskell n'a pas échoué chez Scarf. C'est l'équation économique qui a changé autour de lui.
Pour toute équipe en train de revisiter sa stack ou d'évaluer un nouveau socle technique, cette variable mérite désormais une place explicite dans l'évaluation : non plus seulement « ce langage est-il adapté au problème ? » mais « ce langage supporte-t-il nos modes de travail augmentés ? ». Le phénomène dépasse le développement logiciel : dans les fonctions support aussi, les agents IA s'intègrent aux outils existants et déplacent le goulot d'étranglement — ce n'est plus la capacité d'exécution, c'est la clarté des processus.