Pageboost est né d'un problème très concret : beaucoup d'artisans et de petites entreprises n'ont aucune idée de ce que Google — ou désormais les moteurs IA — affiche réellement d'eux. L'outil fait un diagnostic en trente secondes et propose des recommandations concrètes. Rien de spectaculaire sur le papier. Ce qui m'a marqué, c'est ce que sa construction m'a obligé à réapprendre.
La première leçon, c'est la discipline du périmètre. En conseil, on peut recommander une feuille de route ambitieuse et laisser à d'autres le soin de la découper en lots. En construisant un produit soi-même, chaque fonctionnalité en plus est un coût réel, immédiat, qu'on paie de son propre temps. Ça force à trancher vite entre ce qui sert vraiment l'utilisateur et ce qui flatte surtout la feuille de route.
La deuxième, c'est le rapport aux données réelles. Un audit théorique sur la visibilité d'une entreprise et un audit qui doit tourner sur les fiches Google réelles de centaines d'artisans, avec toute leur hétérogénéité, ce sont deux exercices différents. Les cas limites qu'on préfère ignorer dans une présentation deviennent, en production, la majorité des cas qu'il faut gérer proprement.
La troisième, la plus utile pour mes missions de conseil, c'est la vitesse de la boucle de retour. Avec un produit en production, on sait en quelques jours si une hypothèse tient — un usage réel, un retour d'un premier client, un chiffre qui bouge. Un projet de transformation piloté uniquement par comités perd cette vitesse-là, et c'est souvent ce qui lui manque le plus.
Je ne recommande pas à chaque dirigeant de coder son propre outil. Mais je recommande, à chaque fois que c'est possible, de rapprocher la décision de la réalité d'usage — quitte à accepter un prototype plus rustique, plus tôt, plutôt qu'une présentation plus soignée, plus tard.