Janvier 2023. EdgeSEO fonctionne. Techniquement. Mais ce n'est pas encore un produit.

À ce moment-là, la solution repose sur le EdgeRewriter, une application capable d'exécuter du JavaScript sur la couche CDN pour modifier les pages à la volée. Un client nous a fait confiance pour monter ce MVP. Les recommandations SEO sont déployées, les résultats sont là. Mais chaque déploiement implique du code. Le client transmet ses recommandations, nous les implémentons en interne. Le dispositif est efficace. L'autonomie côté client est inexistante.

Autour de ce POC, il n'y a rien d'autre. Pas de site web, pas de positionnement marketing, pas d'interface utilisateur, pas de discours commercial. Fasterize, l'entreprise qui porte le projet, est spécialisée dans l'optimisation des temps de chargement des sites depuis 2014. Une forte culture webperf, leader français, mais l'écosystème SEO est peu présent en interne.

Je connaissais Fasterize. Trois ans comme CSE sur la solution EdgeSpeed entre 2018 et 2021, avant de partir deux ans. Je revenais cette fois comme First Product Manager. Devant moi : une feuille presque blanche et une conviction. En SEO, le vrai problème n'est pas la stratégie. C'est l'exécution. Ce REX raconte trois années passées à transformer cette conviction en produit. Comment l'autonomie client s'est imposée comme boussole. Et comment l'IA, arrivée au même moment que le développement du projet, a changé ma façon de travailler.

EdgeSEO, une direction claire

Très vite, une évidence s'impose. Si EdgeSEO doit exister, ce sera pour permettre aux consultants SEO de déployer leurs recommandations eux-mêmes, sans dépendre de l'IT ni écrire du code. Parce que dans la plupart des organisations, le SEO n'est jamais prioritaire. Quand un consultant sollicite la tech, les réponses se ressemblent : « tu es sûr que ça va marcher ? », « on verra plus tard ». Pas par désintérêt, mais parce que le SEO n'est pas ce qui fait vibrer des équipes techniques.

C'est à ce moment-là que ChatGPT apparaît. Je l'utilise pour la première fois sur un cas concret : afficher les horaires d'ouverture des pages magasins via des données structurées. Du JavaScript à injecter dans EdgeRewriter. Il me faut près d'une heure pour produire un script qu'un dev aurait écrit en quelques minutes. Mais le script fonctionne. Quelque chose vient de changer. Je peux avancer seul sur des sujets jusque-là réservés aux profils techniques. Tester, comprendre, itérer, sans bloquer le projet. EdgeSEO ne change pas encore de visage. Mais la manière dont je vais le construire, elle, vient de basculer.

2023. Planter les premières graines

Le déclic n'est pas venu d'une nouvelle idée SEO. Il est venu en rédigeant les premières User Stories. <title>, <canonical>, <meta-description>, <hreflang>, données structurées. Les fondamentaux étaient connus, documentés, maîtrisés. Le problème n'a jamais été d'identifier les bonnes recommandations. Le problème, encore une fois, c'était leur déploiement.

Une évidence s'impose. Les consultants SEO passent leur temps dans des tableurs. Google Sheets, CSV, colonnes, exports, imports. Parfois un peu d'AppScript pour bricoler. Leur quotidien n'est pas une interface complexe ni du code, mais des tableaux. Vouloir leur imposer autre chose, c'était créer une friction inutile. Le produit devait s'aligner sur leurs habitudes, pas l'inverse. C'est dans ce contexte qu'est née l'idée de Bulk SEO. Un fichier. Une URL par ligne. Des colonnes dont les noms correspondent directement aux leviers SEO connus. Le fichier est rempli, uploadé, et les optimisations sont déployées. Sans code. Sans intermédiaire.

En démo, l'effet a été immédiat. Jusqu'ici, on parlait d'autonomie en montrant EdgeRewriter. Techniquement irréprochable, mais face à une fenêtre de JavaScript, les SEO avaient du mal à se projeter. On vendait de l'autonomie avec un outil qui nécessitait un développeur. Et ça, tu te le prends en pleine face uniquement quand tu es devant le client. Un First PM qui fait des démos, c'est un First PM qui comprend immédiatement où ça coince. Le décalage était presque comique quand j'y repense. Avec Bulk SEO, la promesse devenait tangible. Copier-coller dans des colonnes plutôt que développer du JavaScript. Des champs qui reprenaient exactement le vocabulaire des audits SEO. Le format était familier, lisible, rassurant.

Dans la foulée, nous avons décliné la même logique avec Bulk Redirection et URL Rewriting. Les applications Bulk étaient nées.

Construire ce qui n'existait pas

En parallèle, il a fallu tout monter. Rien n'était figé. On testait. On ajustait. Le fameux « fake it until you make it », mais avec une intention claire : comprendre ce qui résonnait chez les SEO.

1. Marketing. Pour exister dans cet écosystème, il fallait être présent là où les SEO échangent. Le SEO est un milieu avec ses codes, ses influenceurs, ses rendez-vous. C'est comme ça qu'est né le #TopSEOPost. Chaque semaine, une sélection de contenus SEO sur LinkedIn. Un moyen simple de faire de la veille, de créer des échanges et de comprendre les signaux faibles du marché. Le format m'a autant apporté pour développer notre produit que pour comprendre la communauté elle-même. On a aussi organisé notre premier webinar cette année-là. Je ne vais pas mentir : j'ai répété la présentation cent fois. Pendant le live, aucun plaisir, j'avais l'impression d'être un robot. Mais ça m'a permis de me lancer. Et surtout de structurer notre discours produit. Quand tu dois expliquer ta solution en 45 minutes à des gens qui ne te connaissent pas, tu découvres vite ce qui est clair et ce qui ne l'est pas.
2. Sales. Un site pour présenter la solution. Un discours commercial. Des démos. Je me souviens encore de ma première avec Stéphane, notre CEO, devant une agence SEO. Rien n'était parfait. Mais un message a rapidement émergé : le « Test & Learn ». Dans un métier rythmé par les mises à jour de Google et la pression concurrentielle permanente, la capacité à tester vite et à montrer de l'impact faisait mouche. Cette année-là, on a réalisé environ 30 démos avec l'équipe Sales. Chacune était un crash test. Ce qui était compris en cinq minutes validait une intuition produit. Les questions plus spécifiques révélaient les angles morts.
3. Customer Success. L'Academy a vu le jour dans cette logique. Avec nos premiers clients et l'ambition de rendre tout le monde autonome, il fallait un support. Je peux vous dire que produire des vidéos, les maintenir, c'est un process à mettre en place. Sans rigueur, la documentation devient obsolète et vous créez de la frustration au lieu de l'autonomie.
4. Tech. Nous avancions avec un développeur freelance offshore. Le choix le plus accessible pour démarrer. Suffisant pour planter les bases, mais révélateur d'une limite à venir.

Évidemment, tout ce travail alimentait naturellement la réflexion et la roadmap product. Chaque webinar, chaque démo, chaque échange avec un client faisait remonter des insights. Le produit ne se construisait pas en silo.

2024. Valider le Product Market Fit

2023 nous avait permis de poser les fondations. 2024 devait répondre à une question plus exigeante : est-ce que ça tient à l'échelle ? Les applications Bulk avaient prouvé leur valeur. Mais une limite structurelle est apparue. Une ligne par URL fonctionne pour des périmètres restreints. Pour un e-commerçant avec des dizaines de milliers de pages, le modèle devenait difficilement soutenable.

C'est de ce constat qu'est née Recommandation SEO. Changer l'unité de déploiement. Ne plus raisonner URL par URL, mais par groupes de pages. Utiliser des regex pour cibler des ensembles cohérents. Aller lire directement dans la page les informations utiles et les réutiliser dans les recettes SEO. On passait d'une logique de correction unitaire à une logique de déploiement systémique. Le produit changeait de dimension.

Dans la foulée, nous avons lancé Sitemap, Sitemap Cleaner et DataStorage. Chaque application répondait à un besoin terrain identifié lors des démos ou chez les premiers clients. Inutile de vous dire qu'avec des moyens restreints, on ne part pas dans des devs inutiles. Ou du moins, on limite au maximum le risque. Le First PM se doit d'être frugal.

Les signaux qui confirment

À ce stade, il me manquait un repère clair. J'ai mis en place un dashboard produit avec une north star metric simple : comparer ce qui est déployé directement par les clients à ce qui l'est encore par Fasterize. Mesurer l'autonomie réelle face à l'exécution assistée. Les premiers chiffres ont été sans appel. En 2024, 69 % étaient réalisés directement par les clients. L'autonomie n'était plus une promesse commerciale. C'était une réalité mesurable.

Sur le plan commercial, l'année a confirmé une intuition : EdgeSEO se vend par l'usage. Nous avons signé plusieurs nouveaux clients, souvent après des phases de test. En octobre, un signal extérieur est venu confirmer cette dynamique. EdgeSEO a reçu un SemyAward d'argent dans la catégorie « Produit innovant » au SMX. Pas une fin en soi, mais un indicateur. L'écosystème SEO commençait à nous identifier. En parallèle, un choix structurant : internaliser. Un développeur dédié a rejoint le projet. L'évidence pressentie fin 2023 devenait concrète.

Fin 2024, le Product Market Fit n'était pas encore un acquis. Mais il n'était plus une hypothèse.

2025. Accélérer l'autonomie

Le Product Market Fit était validé. Mais valider ne veut pas dire que tout est réglé. Ça veut dire que les vraies questions commencent. 69 % d'autonomie client en 2024, c'était encourageant. Mais les 31 % restants n'étaient pas un détail. Ce chiffre révélait quelque chose : le produit fonctionnait, mais l'autonomie butait encore sur la friction.

L'UX comme levier stratégique

Recommandation SEO s'était imposée comme l'application centrale. C'était aussi celle qui concentrait le plus de tensions. Les profils non techniques se heurtaient à des parcours trop complexes. Modifier un élément obligeait à refaire tout le tunnel. Dupliquer une recommandation était impossible. Les regex et les sélecteurs CSS devenaient des points de blocage. À ce stade, ce n'était plus un sujet de fonctionnalités. C'était un sujet d'expérience utilisateur.

Nous avons pris une décision structurante : faire de Recommandation SEO un pilote UX. Non pas pour « améliorer l'interface », mais pour traiter l'expérience comme un levier stratégique de l'autonomie. C'était aussi un changement culturel. Fasterize est historiquement une entreprise très tech. En 2025, l'UX est devenue un sujet produit à part entière. Le First PM doit parfois évangéliser avant de livrer. Convaincre que l'UX n'est pas du cosmétique, c'est déjà la moitié du travail.

Se positionner sur un Search qui change

2025 a aussi été marquée par l'accélération des sujets GEO et IA dans le Search. Nouveaux moteurs, nouveaux bots, nouveaux formats. Attendre que les standards soient stabilisés n'était pas une option. Nous avons exploré des pistes comme llms.txt ou la transformation HTML vers Markdown. L'enjeu n'était pas de parier sur une norme figée, mais de démontrer une capacité : EdgeSEO peut transformer une tendance émergente en test déployable, sans dépendance IT.

API Connector est né dans cette logique. Permettre à EdgeSEO de se connecter à l'écosystème réel des clients. Récupérer des données via des API, les stocker, puis les exploiter dans des recettes SEO. L'adoption reste à construire, mais les démos montrent un potentiel énorme. Le terrain de jeu est volatile. Le SEO bouge, l'IA accélère tout. Construire un produit ici, c'est accepter que les règles changent en permanence.

Se confronter au marché

Cette année-là, nous avons exposé davantage EdgeSEO. Conférences en France (SMX, SEO Summit), mais aussi Brighton SEO pour une première sortie à l'international. La culture UK, c'est autre chose. Une énergie différente. Personne ne nous connaît là-bas. On démarre une aventure. Ces formats ont accéléré la boucle de feedback et nourri directement nos arbitrages produit.

L'équipe qui se structure

Autour du projet, une vraie unit EdgeSEO a émergé. Des interactions plus fluides avec les devs, plus de vélocité sur les déploiements. On est passé d'une demi-ressource à 1,5 dev sur le projet. Ça change tout. On avance plus vite, on se positionne plus rapidement sur les demandes clients. Une dynamique s'installe. En fin d'année, cette dynamique s'est étendue côté développement avec les premiers pas vers l'IADD. Des développeurs qui livraient du code pendant plusieurs semaines, en s'appuyant sur des outils d'IA pour comprendre plus vite les services existants, explorer le code, débloquer des situations.

Les chiffres ont confirmé la trajectoire. 74 % des recommandations sont désormais déployées en autonomie par les clients. L'usage global des applications a progressé de plus de 100 %. Il reste du travail. Mais après trois ans, les fondations sont solides. L'autonomie n'est plus une promesse fragile. C'est un socle.

Ce que ces trois ans m'ont appris

1. Un First PM ne peut pas se limiter au produit. Quand tout est à construire, il n'y a pas de frontières entre product, marketing, sales et customer success. Si tu n'es pas exposé aux démos, tu rates les objections réelles. Si tu ne produis pas les premiers contenus, tu ne comprends pas ce qui résonne. Si tu ne vois pas comment les clients utilisent ton produit, tu optimises dans le vide. Le produit ne se construit pas en silo. Chaque webinar, chaque démo, chaque échange client alimente la roadmap.
2. Observer avant de concevoir. Les SEO vivent dans des fichiers CSV et Google Sheets. Pas dans des interfaces complexes. Le jour où j'ai compris ça, Bulk SEO est né. Le produit doit s'aligner sur les habitudes des utilisateurs, pas l'inverse. Cette leçon vaut pour n'importe quel produit B2B.
3. Le First PM doit être frugal. Avec des moyens restreints, chaque décision compte. On ne part pas dans des devs inutiles. On limite le risque. On valide vite. La frugalité n'est pas une contrainte, c'est une discipline qui force la clarté.
4. Évangéliser avant de livrer. Convaincre en interne que l'UX n'est pas du cosmétique, que le positionnement compte autant que la technique, que l'autonomie client est un levier business. Un First PM passe parfois plus de temps à faire bouger les lignes en interne qu'à écrire des specs.
5. L'IA a été un accélérateur, pas un raccourci. Le projet EdgeSEO a grandi en parallèle de ChatGPT et de la montée en puissance des modèles. Au départ, débloquer des sujets techniques sans être développeur. Puis progressivement, un multiplicateur de force pour tenir la cadence sur tous les fronts. Sans cette convergence, EdgeSEO n'aurait pas avancé au même rythme.
6. La north star metric compte plus que la vélocité. J'ai arrêté de piloter à travers le nombre de features livrées. Ce qui a guidé les décisions importantes, c'est la progression de l'autonomie client. Tant que cette métrique avançait, le reste pouvait s'ajuster.
7. Le terrain de jeu est volatile. Le SEO bouge vite, l'IA encore plus. Construire un produit ici, c'est accepter que les règles changent en permanence. Et apprendre à avancer sans attendre que les standards se stabilisent.
8. Les frameworks ne sont pas une fin en soi. En trois ans, je n'ai pas ressenti le besoin d'empiler les méthodologies product ou de construire une bible produit. Ça ne veut pas dire que je travaille sans structure. Mais ajouter une couche de framework pour cocher une case n'apporte rien. J'utilise ce qui m'aide concrètement. Par exemple, la méthode des Pitchs de Basecamp pour creuser un sujet avant de le lancer.
9. Être moteur ne suffit pas. Il faut créer les conditions pour que d'autres accélèrent avec toi. Donner du sens aux arbitrages. Rendre visibles les progrès. L'autonomie client n'est pas uniquement un sujet de fonctionnalités. C'est une trajectoire collective.

Et ce n’est que le début rendez-vous dans 3 ans ou l’année prochaine pour faire un point d’étape. Plein de belles choses sont à venir !