Il existe une pratique que j’apprécie particulièrement et qui reste pour moi le meilleur moyen de repérer les problèmes d’un produit, se nomme le “dog fooding”. Elle consiste à utiliser ses propres produits et services.
C’est malheureusement une pratique que je vois trop peu utilisée. Et encore plus avec l’usage de l’IA où les développeurs font plus facilement confiance au code et aux tests générés.
Les équipes de développement ont tendance à rester focus sur le code et à ne plus ouvrir l’application. On vérifie une fonctionnalité une fois pour valider un ticket, puis on passe à la suivante. Le parcours complet, avec des données réelles et un usage répété, personne ne le fait.
Or, ce que l’on découvre en utilisant son propre produit, ce sont rarement des bugs. Ce sont les frictions du quotidien, celles qui ne justifient pas d’ouvrir un ticket, mais qui pèsent sur ceux qui passent leurs journées dans l’outil.
Ce n’est bien évidemment pas toujours possible. Sur un logiciel métier très spécialisé, on ne peut pas devenir son propre utilisateur. Et même quand on le peut, cela ne remplace pas les retours du terrain.
Il est essentiel pour un développeur d’utiliser le produit qu’il conçoit. Pas uniquement pour vérifier son fonctionnement, mais aussi pour se confronter au quotidien des utilisateurs.
