Aller au contenu
Antoine Le LouetDéveloppeur senior indépendant
← Tous les articles

Idées2 min de lecture

Et si le meilleur outil était celui qu’on n’ajoute pas ?

Nommer le problème avant de comparer les solutions, puis regarder le coût d’adoption et de maintenance au-delà de la première installation.

Un besoin mène à deux pistes : simplifier l’existant ou ajouter un outil.
Comparer les solutions commence par une description commune du besoin.

Nommer le besoin avant la solution

Une démonstration réussie donne souvent envie d’essayer un nouvel outil. Avant de l’adopter, je propose de décrire le travail qui pose problème aujourd’hui. Qui rencontre cette difficulté ? À quelle fréquence ? Ces réponses permettent d’évaluer les fonctionnalités proposées à partir d’un besoin du projet.

Par exemple, une équipe peut avoir du mal à retrouver ses décisions parce que les notes sont dispersées. Avant de changer de logiciel, elle peut essayer de les regrouper au même endroit. Si cela suffit, le problème ne justifiait peut-être pas le coût d’un nouvel outil.

Regarder ce que l’équipe devra entretenir

L’installation est une petite partie de l’adoption. Il faudra comprendre la configuration, transmettre les usages, gérer les mises à jour et savoir quoi faire quand l’outil ne répond plus au besoin. Ce travail mérite d’être comparé au temps que l’on espère gagner, avec les personnes qui l’effectueront réellement.

  • Qui sera capable d’expliquer et de maintenir la configuration ?
  • Quelles données ou pratiques deviennent dépendantes de l’outil ?
  • Comment retrouver le travail existant si l’on décide de changer ?
  • Quel besoin peut être traité avec les outils déjà utilisés ?

Essayer sur un cas limité

Pour cette équipe, un essai pourrait porter sur les décisions d’un seul projet. Les personnes concernées arrivent-elles à retrouver la dernière décision et sa justification sans demander à un collègue ? Définir cette question avant le test donne un critère pour évaluer l’outil après sa découverte.

Il est également utile de fixer une manière de terminer l’essai. Quelles traces conserver ? Qui décide de la suite ? Comment réintégrer les données si l’on ne poursuit pas ? Préparer cette sortie rend l’expérimentation plus facile à limiter et son résultat plus simple à discuter.

Choisir ce qui simplifie le travail réel

L’essai peut aussi montrer que l’outil répond à une contrainte difficile à traiter autrement. Si l’équipe retrouve mieux ses décisions grâce à une recherche adaptée, ce gain mérite d’être comparé au travail de maintenance et de migration évalué plus tôt.

À la fin de l’essai, consignez ce qui a permis de trancher, y compris les difficultés rencontrées. Si le besoin change, l’équipe pourra reprendre cette décision avec son contexte.