Comment j'évalue de nouveaux outils ?

En tant que développeur, on voit régulièrement passer de nouveaux outils, bibliothèques ou frameworks, mais comment faire le tri ? Je vous propose de partager la méthode que j'utilise pour évaluer mes découvertes lorsque je fais de la veille.

Trois questions pour évaluer

Lorsque j'explore une technologie, je cherche à répondre à trois questions :

• Quel problème cherche-t-elle à résoudre ? Si ce problème ne me concerne pas, je n'ai pas forcément besoin d'aller plus loin.
• Comment résout-elle ce problème ? Je veux comprendre à quoi ressemble le code et ce que je vais devoir mettre en place pour utiliser la solution.
• Quels sont les compromis ? Une solution peut apporter ses propres contraintes (qui peuvent parfois être plus problématiques que le problème initial).

L'objectif n'est pas de déterminer si une technologie est bonne ou mauvaise dans l'absolu, mais si elle correspond à mes besoins et à ma manière de travailler.

Identifier le problème avant de se lancer

Quand je découvre un outil, j'essaie d'abord de comprendre rapidement à quoi il sert. Ce n'est pas toujours évident : les pages d'accueil mettent parfois en avant des phrases marketing très génériques, sans expliquer concrètement ce que l'outil apporte.

Les documentations proposent toutefois souvent des pages intitulées « Why XXX? » qui permettent de répondre rapidement à la question. Il est aussi possible de parcourir les issues GitHub pour voir si un autre utilisateur a déjà répondu à cette question. Sinon, il faudra tester l'outil pour comprendre son fonctionnement et le type de problème qu'il résout.

Une fois ce problème identifié, je peux me poser deux questions complémentaires :

• Est-ce un problème que je rencontre dans mes projets ?
• Est-ce que j'ai besoin d'une bibliothèque pour le résoudre ?

Même si la réponse n'est pas immédiatement positive, je peux poursuivre l'exploration pour mieux comprendre la proposition.

Lire la documentation et expérimenter

Pour comprendre comment une technologie fonctionne, je passe directement par sa documentation. Je parcours les explications et, en parallèle, je code de petits exemples pour vérifier que j'ai compris et que je suis capable d'adapter ce que je lis.

Pas besoin de construire tout de suite un projet complexe. De petits blocs suffisent pour explorer les mécanismes de base, faire apparaître des questions et voir à quoi ressemble réellement le code.

Cette étape me permet aussi d'évaluer la qualité de la documentation. Un outil peut être intéressant, mais si sa documentation ne permet pas de s'en sortir seul, son utilisation au quotidien va être pénible (c'est un peu comme monter un meuble avec un plan qui explique mal comment les pièces s'assemblent...).

En expérimentant, je cherche autant à comprendre les avantages qu'à identifier les contraintes.

Chercher des avis qui contredisent le mien

Une fois mon propre avis formé, je vais le confronter à celui d'autres développeurs, par exemple sur YouTube ou Hacker News. On a tous des préférences et des biais : ma première analyse peut être incomplète, ou je peux être passé à côté d'un avantage important.

Je cherche donc volontairement des avis qui vont à l'opposé du mien :

• Si je n'ai pas aimé un outil, je regarde les arguments des personnes qui l'apprécient.
• Si je suis enthousiaste, je cherche plutôt les critiques et les limites rencontrées par d'autres.

Le but n'est pas de confirmer ce que je pense déjà, mais de comprendre ce qui pourrait me faire changer d'avis ou nuancer mon point de vue.

L'ordre est important : je fais cette recherche après mon exploration personnelle. Je préfère d'abord me faire une idée par la pratique, sans être influencé par les opinions des autres, puis utiliser leurs retours pour remettre mon jugement en question.

Valider dans un projet concret

Si une technologie me convainc, l'étape suivante consiste à l'utiliser dans un vrai projet. Cela peut être un projet personnel ou un projet professionnel si je suis suffisamment en confiance.

Les petits essais permettent de comprendre les mécanismes, mais certains avantages et inconvénients n'apparaissent qu'avec une utilisation réelle. Un cas particulier peut révéler une limite qu'on n'avait pas anticipée, ou au contraire confirmer l'intérêt de l'outil.

À l'issue de cette expérience, plusieurs décisions sont possibles :

• L'outil fonctionne bien et ses compromis me conviennent : je l'adopte.
• Les contraintes sont trop importantes : je le laisse de côté.
• Ses limites dépendent du contexte : je le réserve à certains types de projets.

Quand l'expérience n'est pas concluante, je prends des notes sur ce qui fonctionnait et ce qui posait problème. Ce choix n'est pas forcément définitif ni valable pour tous les projets, et je peux aussi être amené à changer d'avis avec le temps.

C'est ce qui m'est arrivé avec React. Lors de ma première exploration, je n'avais pas du tout aimé son approche et je préférais Vue.js. Je l'ai donc ignoré pendant un moment. Puis React a évolué, notamment avec l'arrivée des hooks, et en y revenant j'ai fini par l'apprécier.

Quelle place pour l'IA ?

On peut être tenté de demander directement à une IA son avis sur un outil ou de lui faire comparer plusieurs technologies. Mais sa réponse ne remplace pas une expérimentation personnelle, car les IA s'appuient sur des contenus et des opinions déjà existants, sans avoir l'expérience de mes projets ni connaître mes préférences.

La formulation de la demande peut aussi renforcer un biais de confirmation : la manière de poser la question peut orienter la réponse. Vous pouvez utiliser l'IA dans un second temps, mais pour une première exploration, je ne pense pas que ce soit un bon réflexe.