Pourquoi les technologies « ennuyeuses » gagnent : la puissance d'une stack technologique éprouvée

Dans la course pour livrer plus vite, monter en charge davantage et innover plus fort, il est tentant de se tourner vers l'outil le plus récent disponible. Un nouveau framework ou un nouveau langage de programmation semble enthousiasmant. Cependant, lorsqu'il s'agit de livrer des produits qui fonctionnent (et continuent de fonctionner), c'est souvent le soi-disant «ennuyeuxdes outils qui gagnent discrètement.

Pourquoi ? Parce qu'ils ont été testés et éprouvés – non seulement en théorie, mais dans le monde réel. Bienvenue dans la puissance de la stack technologique éprouvée.

La stack technologique éprouvée : de quoi s'agit-il ?

La stack technologique éprouvée n'est pas simplement ancienne. Elle est fiable, bien comprise et résout les problèmes sans en créer de nouveaux. Pensez Java, Git, ouMarkdown. Ce ne sont pas des antiquités – en fait, ils continuent d'évoluer tout en restant fidèles à leurs fonctions essentielles.

De nouveaux outils, brillants et séduisants, sont tentants. Mais lorsque votre attention doit soudainement passer de la livraison à la gestion de crise, le coût devient évident : les projets ralentissent, les équipes s'épuisent, et ce qui a commencé comme «innovative» se transforme en problème.

Une histoire de marteaux (et pourquoi c'est important dans la tech)

Commençons par une histoire issue d'un domaine totalement différent pour planter le décor.

J'ai récemment observé un professionnel expérimenté charpentier testez un étrange nouveau marteau – un marteau sans tête avec un manche lesté que l'on saisit comme un poing. Le design semblait futuriste. Cependant, une fois mis à l'épreuve, les résultats étaient décevants : le nouveau marteau était bien moins précis, prenait plus de temps pour enfoncer les clous et causait même des douleurs à la main. Pire encore, lorsqu'on tentait de retirer des clous, il endommageait souvent leurs têtes. Malgré son apparence peu conventionnelle, il ne surpassait pas le marteau traditionnel. En réalité, il rendait la tâche plus difficile et moins efficace.

Innovation vs efficacité

Vous pourriez objecter : «Mais le charpentier était simplement plus habitué au vieux marteau !» Bien qu'il soit vrai que l'expérience joue un rôle, cela change-t-il le résultat ? Un clou tordu reste un clou tordu. Si ce marteau était utilisé dans une véritable rénovation de maison, des plaintes suivraient certainement.

La leçon est que, quelle que soit l'innovation d'une conception, si l'outil n'accomplit pas le travail efficacement, il ne vaut pas l'engouement qu'il suscite.

Tout consiste à faire aboutir le travail dans le développement logiciel

Le même principe s'applique à la technologie. Ce n'est pas parce qu'une stack technologique est nouvelle et prometteuse qu'elle conviendra à vos besoins.

La technologie peut sembler «ennuyeux», mais si ce choix repose sur des exigences de projet solides et produit systématiquement des résultats fiables et durables, c'est ce qui compte vraiment.

Dans tous les domaines (qu'il s'agisse de menuiserie ou de développement logiciel), les experts sont appréciés pour leur expertise éprouvée plutôt que pour leur course aux tendances. Si j'ai passé dix ans en tant que développeur Java, mon rôle est de livrer des solutions Java, et non de créer de la confusion en expérimentant avec Scala ou Rust par simple goût de la nouveauté. Si j'introduis une complexité inutile en utilisant un langage de programmation différent, dois-je m'étonner que mes collègues aient du mal à comprendre mon code, ou que les bugs se multiplient ?

La morale de l'histoire : l'innovation est une bonne chose, mais seulement si elle permet réellement d'améliorer l'efficacité.

Exemples concrets

Lorsqu'il s'agit du «ennuyeuxparmi les technologies que j'utilise quotidiennement – outre Java, que j'ai déjà mentionné – deux outils (ou plutôt concepts) se distinguent. Ce sont regex et Markdown, et ci-dessous je vais vous montrer comment ils peuvent simplifier votre travail.

Expressions régulières (regex)

J'ai rencontré pour la première fois regex grâce àVim, que j'ai commencé à utiliser il y a quatre ans (peu avant qu'Emacs ne fasse son entrée dans ma boîte à outils). Cependant, les regex ne sont pas qu'une astuce Vim. Le concept est environ 40 ans plus ancien et s'est fermement intégré dans de nombreux éditeurs de texte et langages de programmation. Aujourd'hui, les regex font partie intégrante de mon travail dans IntelliJ, divers éditeurs de texte, outils Unix, et même comme outil pour la logique applicative.

Les expressions régulières sont à la fois un cadeau et une malédiction. C'est comme un sort magique qui, lorsqu'il est utilisé correctement, peut transformer un texte chaotique en une perfection structurée. Mais la moindre erreur ? Félicitations, vous venez d'invoquer une incantation illisible que personne (y compris votre futur vous-même) ne peut déchiffrer. Et n'oublions pas le mal de tête potentiel lié à l'oubli d'écrire des tests unitaires pour vos expressions régulières.

Néanmoins, les regex restent un outil incontournable pour résoudre un problème spécifique : le traitement des tâches d'édition répétitives et fastidieuses.

Par exemple, prenons une classe comme Numbers qui nécessite une refactorisation. L'exemple ci-dessous est simplifié, mais imaginez des centaines de lignes, toutes suivant un schéma similaire, en attente d'être ajustées.

Au lieu de modifier manuellement chaque ligne, vous utilisez une regex. Un seul motif définit quoi doit changer, l'autre précise comment pour le modifier.

En un instant, chaque ligne correspondante est transformée :

En examinant le résultat, vous réalisez qu'il reste encore une marge d'amélioration. Une regex de remplacement le simplifie encore davantage :

Maintenant, il vous reste cette version bien plus épurée :

Une dernière étape de polissage manuel, et voilà :

Voici le plus beau : que vous mettiez à jour une ligne ou mille lignes, écrire la regex prend le même temps (histoire vraie).

Comme vous pouvez le constater, vous pourriez parcourir chaque ligne et les corriger manuellement. Ou vous pourriez utiliser les expressions régulières et observer des modifications précises et groupées en une fraction du temps nécessaire pour le faire manuellement.

Markdown

En 2004, John Gruber a introduit Markdown, un langage de balisage léger conçu pour la simplicité. En moins d'un an, il a atteint sa version stable finale (v1.0.1) et, étonnamment, cette version est restée inchangée depuis.

C'est parce que Markdown a été construit sur une idée brillamment minimaliste : il utilise quelques marqueurs simples pour formater le texte, tels que les en-têtes, les polices en gras et en italique, les listes, les énumérations et quelques autres éléments de formatage essentiels. À l'époque, c'était tout ce dont la plupart des développeurs avaient besoin.

Bien que vous puissiez obtenir le même résultat (et bien plus encore) en écrivant directement du HTML, veuillez comparer ces deux exemples ci-dessous.

HTML

Markdown

J'ai mentionné plus tôt que la première et unique version officielle de Markdown a été publiée en 2004. Curieusement, près de deux décennies plus tard, la plupart des personnes qui écrivent du texte n'ont encore besoin que d'un petit sous-ensemble des fonctionnalités HTML pour accomplir leurs tâches.

Bien sûr, ils n'utilisent pas Markdown exactement de la même manière qu'en 2004. Ils travaillent plutôt avec l'une de ses nombreuses variantes modernes – des variations qui développent l'idée originale tout en préservant sa simplicité fondamentale. Ces dérivés de Markdown sont activement développés, de nouveaux éditeurs apparaissent régulièrement pour les prendre en charge, et des applications entières ont été construites sur la base de Markdown tout en ajoutant des extensions spécialisées pour divers cas d'usage.

Si vous êtes développeur, vous avez peut-être remarqué que de nombreux outils largement utilisés génèrent des fichiers Markdown par défaut. Cette extension .md dans README.md ? Elle est créée automatiquement chaque fois que vous démarrez un nouveau dépôt sur GitHub, GitLab ou Bitbucket. Même les produits Atlassian comme Jira et Confluence prennent en charge l'édition directe en Markdown depuis des années (du moins avant que les décideurs d'entreprise ne décident de les orienter dans une autre direction).

À travers tous ces changements, la force essentielle de Markdown reste la même : la simplicité.

Le fait que README.md soit automatiquement créé dans chaque nouveau dépôt n'est pas un hasard ; il sert de rappel subtil de la part des forges Git que Markdown excelle tout simplement pour rédiger de la documentation.

Chaque année, de nouveaux outils propriétaires inondent le marché, chacun promettant de révolutionner notre façon d'écrire et de collaborer. Ils arrivent avec des fonctionnalités sophistiquées, des interfaces élégantes et des assistants propulsés par l'IA. Soyons réalistes : avez-vous vraiment besoin de tout cela ? Quoi de mieux qu'un format universel qui fonctionne avec n'importe quel éditeur de texte ?

• IntelliJ ? Supported.
• Visual Studio Code ? Supported.
• Notepad.exe ? Supported. (Et vous n'avez même pas besoin de coloration syntaxique pour écrire du Markdown efficacement.)

Markdown + Git = le workflow parfait

Besoin d'une solution de documentation pour toute votre équipe ? Vous en avez déjà une. Si vous avez ne serait-ce qu'un peu d'expérience en tant que développeur, vous l'utilisez depuis des années. Les systèmes de contrôle de version (comme Git) sont la réponse.

Réfléchissez-y – ce workflow est devenu une seconde nature pour les développeurs :

Le meilleur aspect est la pleine propriété de vos fichiers. Si vous décidez un jour de ne plus utiliser GitHub, tous vos fichiers Markdown restent sur votre ordinateur. Il n'y a aucun verrouillage, aucune complication propriétaire et aucun logiciel spécial requis pour les lire.

En fin de compte, Markdown n'est pas seulement «suffisamment bonpour la documentation ; c'est la référence absolue.

Éloge de la technologie « ennuyeuse »

Je vous ai présenté deux exemples spécifiques, regex et Markdown, mais ce ne sont là que la partie émergée de l'iceberg. Le véritable enseignement n'est pas que vous devriez tout abandonner et commencer à les utiliser partout (bien que je ne vous en dissuaderais pas).

Il s'agit plutôt d'adopter un certain état d'esprit : l'habitude de se demander si les dernières tendances à la mode sont réellement nécessaires lorsque des outils éprouvés résolvent déjà votre problème.

Avant de vous lancer sur la prochaine technologie, posez-vous les questions suivantes :

1. L'ancienne solution est-elle fiable et suffisante pour la tâche ?
2. Est-ce indépendant des décisions d'une seule entreprise ?
3. L'équipe le comprend-elle déjà ?
4. L'intégration de nouveaux collaborateurs sera-t-elle facile ?
5. Avez-vous déjà eu du mal à trouver des explications à ses bizarreries ?
6. Existe-t-il des milliers de réponses d'experts à des problèmes obscurs ?

Si la réponse est oui à la plupart de ces questions, félicitations – vous avez trouvé un ‘ennuyeux’ une technologie qui fonctionne.

« Ennuyeux » = plus de temps pour ce qui compte

Une stack technologique stable et prévisible signifie moins de temps passé à se battre avec ses outils et plus de temps consacré à la résolution de véritables problèmes métier. Elle libère de l'énergie pour les objectifs stratégiques au lieu de s'enliser dans le débogage de cas limites.

Maintenant, comparez cela avec ce scénario :

• Vous choisissez quelque chose de nouveau et d'excitant.
• Vous vous sentez très bien pendant une semaine, peut-être même un mois.
• Vous mettez à jour votre CV avec ‘technologie innovante’.

Mais alors…

• À mesure que le projet mûrit, votre base de code ne ressemble plus aux exemples bien ordonnés de la documentation officielle.
• Votre client s'impatiente à mesure que les progrès ralentissent.
• Les fonctionnalités sont publiées moins fréquemment tandis que les bugs persistent.
• Vous constatez que des ressources complètes de dépannage n'existent pas encore.

Le compromis en valait-il la peine ?

Répondre aux préoccupations

Il reste une question en suspens que nous n'avons pas encore abordée.

“Si je m'en tiens aux technologies dites « ennuyeuses », est-ce que je risque une stagnation professionnelle ? Vais-je devenir ce développeur qui aura du mal à trouver un emploi dans les cinq prochaines années ?“

Prenons une grande inspiration. J'ai deux réflexions à ce sujet.

1. La meilleure technologie était déjà « ennuyeuse » avant votre naissance

Vous avez déjà entendu parler du couplage et de la cohésion ? Ce sont des principes fondamentaux de la conception logicielle – des concepts qui remontent aux années 1970, bien avant la programmation orientée objet, la conception pilotée par le domaine et la plupart de ce que nous considérons comme les bonnes pratiques modernes. Pourtant, ils restent tout aussi pertinents aujourd'hui.

Cela s'explique par le fait que de nombreuses bonnes pratiques et paradigmes architecturaux modernes ne sont en réalité que des raffinements ou des cas particuliers d'anciens principes. Maîtrisez les principes, et vous serez en mesure de reconnaître les schémas sous-jacents aux nouvelles tendances, sans avoir à courir aveuglément après chaque nouvelle technologie. Vous comprendrez les dépendances, les compromis et (surtout) le moment où une tendance n'est qu'une idée remballée avec un meilleur marketing.

2. Comment le « nouveau » devient « ennuyeux »

Pas tous les de pointe l'outil atteint le «ennuyeux’ mais essentiel club. La réalité est que tous les nouveaux outils ne survivent pas assez longtemps pour mériter ce statut. Si vous participez à des conférences IT (en particulier celles sponsorisées par des fournisseurs), vous pourriez avoir l'impression que passer à la dernière solution est urgent, nécessaire et garanti de réussir. Le message est toujours le même :

“Vous DEVEZ passer à cette technologie. Hier.”

“Tous les acteurs clés l'utilisent.”

Changeons de perspective. Imaginez dix startups prometteuses, chacune présentant son outil révolutionnaire. Un an plus tard, neuf d'entre elles ont disparu. Combien de ces histoires d'échec entendrez-vous à la conférence de l'année prochaine ? Aucune.

Ce que vous observez est un biais de survie : l'illusion que chaque nouvel outil est un succès parce que seuls les survivants sont célébrés.

Ainsi, si une nouvelle technologie est véritablement destinée à devenir fiable… pourquoi ne pas attendre de voir si elle survit réellement ?

Quand faire le grand saut (et quand se détendre avec du popcorn)

Cela dit, si quelque chose vous enthousiasme véritablement – ou semble trop prometteur pour être ignoré – n'hésitez pas à l'explorer ! Soyez simplement prudent quant à son déploiement dans des situations où un échec pourrait avoir un impact significatif sur votre carrière.

Regardez comment Rust a été introduit dans le noyau Linux. Au lieu de réécrire les composants essentiels du jour au lendemain, ils ont commencé petit, en autorisant Rust uniquement dans des modules optionnels. Si cela fonctionne, tant mieux. Si l'intégration de Rust ne se déroule pas comme prévu, le système central reste inchangé.

Réflexions finales : tout ce qui est ancien ne mérite pas d'être conservé

Bien sûr, tous les anciens outils ne méritent pas de rester dans notre stack. Certaines technologies disparaissent pour de bonnes raisons, telles que des formats propriétaires, des incertitudes juridiques ou une inefficacité pure et simple. L'essentiel est de savoir faire la différence entre ‘ennuyeux mais excellent’ et ‘obsolète pour une raison’.

Les outils qui comptent le plus ne sont pas ceux qui impressionnent les recruteurs ou qui paraissent tendance sur une présentation. Ce sont ceux qui font le travail, jour après jour, sans défaillance. Alors la prochaine fois que vous choisirez une pile technologique, rappelez-vous : l'ennui, c'est beau.