Choisissez une technologie ennuyeuse, revisité (2025)

• Le principe "Choose Boring Technology", qui consiste à se concentrer sur une stack technologique vérifiable, devient encore plus important à l’ère des outils de code IA
• Les entreprises doivent utiliser de manière stratégique leurs "innovation tokens" limités sur des technologies dont la fiabilité est prouvée
• Les outils modernes de code IA génèrent un code qui semble plausible pour presque n’importe quelle stack, mais dès que deux technologies ou plus sont inconnues de l’utilisateur, il devient impossible de vérifier les erreurs
• Dans une stack déjà bien maîtrisée, les outils de code IA agissent comme un force multiplier (outil d’amplification des capacités), mais avec des technologies inconnues, ils se transforment en simple béquille de dépendance
• Plus la qualité du code généré par l’IA augmente, plus il devient difficile de repérer les problèmes, ce qui accroît la valeur d’une compréhension approfondie des technologies

---

Réaffirmation du principe Choose Boring Technology

• L’auteur partageait déjà il y a 10 ans le point de vue du texte de Dan McKinley, "Choose Boring Technology", et n’a pas changé d’avis une décennie plus tard
  • Au démarrage d’un nouveau projet, il se demande d’abord : « Est-ce un prétexte pour apprendre quelque chose de nouveau, ou pour résoudre un problème ? »
  • S’il s’agit d’apprendre quelque chose de nouveau, il limite l’inconnu à un seul élément ; s’il s’agit de résoudre un problème, il reste sur des technologies qu’il connaît déjà
• L’arrivée des LLM et des outils de code IA agentiques rend ce principe encore plus critique

L’argument central de McKinley

• Les entreprises disposent d’un nombre limité d’"innovation tokens" et doivent les investir stratégiquement dans des technologies établies et bien comprises, plutôt que dans des technologies séduisantes mais non éprouvées
• Les technologies ennuyeuses ont des modes de défaillance (failure modes) connus, des fonctionnalités bien comprises et une fiabilité opérationnelle démontrée
  • Quand une panne survient à 3 heures du matin, mieux vaut déboguer une technologie pour laquelle il existe déjà des réponses sur Stack Overflow que partir explorer l’inconnu
• Ce principe était vrai en 2015 et il l’est toujours aujourd’hui

Les outils de code IA comme nouvelle variable

• Les outils modernes de code IA produisent un code d’apparence experte pour presque n’importe quelle stack imaginable
  • Si l’on demande à Claude ou Copilot d’implémenter des microservices sur Kubernetes, une fédération GraphQL ou un framework JavaScript récent, ils renvoient du code qui suit les conventions et s’exécute
• Dès qu’on utilise au moins deux technologies que l’on ne maîtrise pas, il n’existe pratiquement aucun moyen de vérifier si l’IA fournit un résultat erroné
  • Malgré leurs capacités impressionnantes, les LLM hallucinent sur les détails techniques
• L’auteur a vu des ingénieurs accepter tel quel du code problématique généré par l’IA
  • utilisation d’API obsolètes, implémentation d’antipatterns de sécurité, problèmes de performance subtils qui n’apparaissent qu’en charge de production
  • Le code avait l’air correct, respectait les conventions de nommage et gérait correctement les erreurs, mais il était faux d’une manière que seule une personne familière avec la technologie pouvait détecter

Technologie inconnue + code IA = multiplication de l’incertitude

• Combiner une technologie peu familière avec du code généré par l’IA ne revient pas à additionner les inconnues, mais à les multiplier
  • Impossible de savoir si le choix du framework est pertinent
  • Impossible de savoir si l’implémentation de l’IA suit les best practices
  • Impossible de distinguer dans le code généré ce qui relève du boilerplate et ce qui constitue la logique métier centrale
  • Impossible de savoir quels modes de défaillance surveiller
• On dépasse largement le simple cargo-culting : on est au niveau du "cargo-culting fois 2 356"

Là où les technologies ennuyeuses et l’IA créent une synergie

• Quand on comprend la stack sous-jacente, les outils de code IA deviennent extrêmement puissants
  • Comme il connaît bien Rails, l’auteur peut repérer quand Claude fait une suggestion douteuse (avec l’aide de context7)
  • Comme il comprend les spécificités de JavaScript, il peut vérifier les suggestions de Copilot
• L’IA devient un force multiplier sur des technologies déjà comprises, mais se réduit à une béquille sur des technologies inconnues

Recommandations pratiques à l’ère de l’IA

• Lorsqu’on évalue une nouvelle technologie, il faut d’abord se demander : « Si l’IA génère le code d’implémentation de cette technologie, serai-je capable de le relire correctement ? »
  • Si la réponse est « non », il ne faut pas utiliser cette technologie dans un contexte mission-critical
• Si l’on décide d’apprendre quelque chose de nouveau (et qu’on ne dispose que d’un seul innovation token), il faut réellement investir du temps pour l’approfondir suffisamment afin de pouvoir vérifier les suggestions de l’IA
  • Il ne faut pas se contenter de copier-coller en espérant que ça marche
• Il faut résister à la tentation d’adopter plusieurs nouvelles technologies à la fois sous prétexte que les outils d’IA le permettent
  • L’IA donne l’impression qu’on peut gérer simultanément un nouveau langage, un nouveau framework et une nouvelle infrastructure, alors qu’on ne peut en valider correctement aucun

Risques accrus à l’ère de l’IA et conclusion

• L’idée initiale de "choose boring technology" visait à réduire la complexité opérationnelle et la charge cognitive, et cette préoccupation reste pleinement valable
• À l’ère de l’IA, un risque supplémentaire apparaît : la false confidence (fausse confiance en soi) générée par une IA capable de produire un code d’apparence experte pour n’importe quelle stack
• La qualité du code généré par l’IA rend paradoxalement les problèmes plus difficiles à détecter
  • Autrefois, le mauvais code avait l’air mauvais ; aujourd’hui, il faut vraiment comprendre le domaine pour repérer les problèmes subtils
• Pour résoudre des problèmes, il faut utiliser ce que l’on connaît déjà ; pour apprendre quelque chose de nouveau, il faut se concentrer sur l’apprentissage ; et il ne faut pas confondre compréhension et code généré par l’IA
• La technologie la plus ennuyeuse de la stack est peut-être celle que l’on comprend suffisamment bien pour remarquer quand l’IA se trompe
  • Dans un monde où l’IA peut générer avec assurance des milliers de lignes de code dans une technologie qu’on n’a jamais utilisée, la valeur de cette compréhension est plus grande que jamais