J'ai refait mon site avec Claude, de WordPress à React, sans expérience technique

Notes de terrain. La version honnête, pas la version LinkedIn.

Notes de terrain d'un acheteur qui a migré theprocurementor.com de WordPress à une app React custom, sans écrire une ligne de code lui-même. La version honnête, pas la version LinkedIn. Je vous détaille mon expérience et mes leçons sur le vibecoding dans cet article. Vous trouverez les détails sur le processus et comment éviter mes erreurs dans une seconde partie.

Si vous voulez juste lire les leçons pour les achats et passer le récit du processus.

Pourquoi j'ai décidé de migrer

Mon site WordPress faisait le job. Pages de services, articles, formulaire de contact. Rien de glorieux, mais rien de cassé.

Trois choses se sont accumulées jusqu'à ce que je décide de tout casser.

D'abord, les plugins. Chaque besoin un peu spécifique passait par un plugin de plus. Page builder, SEO, formulaire, anti-spam, cache, sécurité, performance. À chaque mise à jour, un truc se déréglait quelque part. Je passais plus de temps à entretenir l'écosystème qu'à produire du contenu.

Ensuite, ma propre indiscipline SEO. WordPress me cachait la mécanique sous une interface. Je remplissais les champs Rank Math sans vraiment comprendre ce que je faisais des canonicals, des sitemaps, du schema markup. Tant que ça marchait à peu près, je ne creusais pas. C'était précisément le problème : je n'apprenais rien.

Enfin, et c'est ce qui a déclenché la décision : je ne pouvais pas vraiment utiliser l'IA pour faire évoluer mon site. Claude pouvait me suggérer du code. WordPress me forçait à passer par un thème enfant, un constructeur visuel, ou un plugin custom. La friction entre "j'ai une idée à 22h" et "c'est en ligne" restait élevée. Pendant ce temps, je voyais passer sur LinkedIn des posts de gens qui montraient leur site refait en quinze minutes avec un agent IA.

Trois raisons accumulées.

J'ai pensé : si eux le font en quinze minutes, moi, en non-technique, je le fais en deux jours. Allez, un week-end max.

C'est là que j'aurais dû me méfier.

L'attente naïve qui m'a coûté plusieurs semaines.

Le décompte qui suit, en cinq étapes, résume mieux l'expérience que n'importe quel paragraphe.

Le vrai chrono d'un projet vibe-codé (à en croire LinkedIn vs. la vraie vie)

Spoiler : l'étape 5 ne s'arrête jamais.

Le vrai chrono, en cinq étapes.

La réalité du job de fond

Le cœur du travail a pris bien plus longtemps. Pas parce que l'IA n'arrivait pas à coder, au contraire, elle code très bien. Mais parce qu'un site n'est pas que du code.

Il a fallu gérer la migration du sous-domaine, transférer manuellement un nombre d'éléments que je n'avais pas anticipé, et reconstruire de zéro tout ce que WordPress gérait nativement sans que je m'en rende compte. Le sitemap, par exemple. Sous WordPress, un plugin le génère et le maintient. Dans une app React custom, c'est à toi de décider comment il est généré, quand il se met à jour, quelles routes il contient, et comment Google y accède.

J'ai dû installer Payload CMS pour gérer mes contenus. Intégrer mes propres modules SEO. Mettre en place GitHub. Configurer le déploiement sur Vercel. Connecter une base de données. Lancer des procédures de tests. Comprendre le rythme commit-push-deploy.

J'avais la chance de connaître la plupart de ces outils par d'autres projets. Mais connaître l'existence d'un outil et l'utiliser sérieusement sont deux métiers différents. Tu ne fais pas tourner Payload CMS, Vercel, Supabase et GitHub ensemble en quinze minutes parce que tu en as entendu parler. Tu te bats avec chacun.

À ça s'est ajouté un changement opportuniste : passer de Calendly à Cal.com pour gagner en granularité sur la prise de rendez-vous et bénéficier d'options gratuites. Pourquoi pas. Quelques heures de plus pour réécrire l'intégration, tester les webhooks, refaire les liens de tracking.

Tout ce que WordPress gérait nativement, à reconstruire.

L'autre piège : le vibe coding sans fin

La deuxième partie a été plus pernicieuse. Une fois la structure debout, je me suis dit : tant qu'à faire, pourquoi pas un funnel personnalisé pour guider les prospects par typologie de besoin ? Des choses à peu près impossibles à faire proprement sous WordPress devenaient triviales à coder.

J'ai conçu, écrit, et testé plus de soixante pages de funnel. Pas parce qu'il en fallait soixante. Parce qu'à chaque test, je voyais une variante à essayer. Une autre formulation pour le CPO indirect, une autre pour le DAF, une autre pour le directeur industriel. Chaque variante demandait son arbo, son copy, son call-to-action, ses tests.

J'ai aussi construit des outils d'évaluation et de démonstration pour montrer aux prospects ce que je peux livrer. L'exécution était rapide. L'idéation et le test, eux, étaient sans fond.

C'est le grand piège du vibe coding que personne ne raconte sur LinkedIn : tu peux te perdre dedans. L'outil ne te résiste pas. Il dit oui à toutes les idées. Tu n'as plus de friction technique pour arbitrer entre "bonne idée" et "lubie nocturne". D'où les sessions qui finissent à deux heures du matin parce qu'une page de funnel ne convertit pas comme tu voulais.

Quand un développeur est dans la boucle, son temps facturé est ton arbitre. Sans lui, ton seul garde-fou c'est ta propre discipline. Et la discipline, en vibe coding, n'est pas le réflexe par défaut.

Le piège du vibe coding sans fin.

Les problèmes qui restent

Mon sitemap est aujourd'hui un jeu de whack-a-mole. À chaque tentative de correction d'un problème, j'en crée deux autres ailleurs. Une route que je rends statique perd ses paramètres dynamiques. Une métadonnée que je centralise se retrouve écrasée par un override. Une redirection que j'installe casse un canonical qui marchait.

Résultat brut : mon SEO est moins bon aujourd'hui qu'avant la migration. Avec l'espoir, assez sérieusement fondé, qu'il sera meilleur dans six mois. Mais aujourd'hui, je paye le coût de la transition. Je l'écris parce que c'est la réalité, et parce que les posts qui te vendent une migration "en un week-end" omettent systématiquement cette phase.

Le coût de la transition, payé maintenant.

Et pourtant, deux fois plus de rendez-vous

Si je m'arrêtais au paragraphe précédent, le bilan donnerait un tableau gris. Il manque la moitié de l'histoire.

Depuis la refonte, ma prise de rendez-vous a doublé. Pas grâce au SEO, qui est temporairement moins bon, je l'ai écrit. Grâce à un site qui, enfin, incarne vraiment mon offre. Les pages services racontent ce que je fais sans détour, les démos montrent ce que je peux livrer, le funnel guide chaque persona vers la conversation qui le concerne. C'est devenu un outil de vente, pas un dépliant.

Pour un cabinet de conseil dont le pipeline ne dépend pas du volume mais de la qualité des entrants, le différentiel est massif. Le SEO finira par revenir dans six mois. Les rendez-vous, eux, sont là maintenant.

Et pourtant : deux fois plus de rendez-vous.

Bonus : un socle technique que je n'avais pas

J'ai gagné une masse de compétences que je n'avais pas prévu d'acquérir, et que je suis content d'avoir aujourd'hui. Je sais maintenant ce que fait concrètement un canonical, pourquoi un sitemap XML compte, comment fonctionne un pipeline CI/CD, à quoi sert une variable d'environnement, pourquoi tu sépares ton schéma de base de tes données. Je sais ouvrir un fichier de configuration sans paniquer, lire un log d'erreur de build, et identifier si un bug vient du front, du back, ou de la base.

Ce socle nourrit désormais mes interventions de conseil. Quand je parle digitalisation de la fonction achat avec un DAF, je ne récite plus des concepts vus en conférence, je sais ce qu'il y a derrière, ce qui coince en pratique, et ce qu'un projet vibe-codé représente vraiment en temps et en complexité. C'est un gain de crédibilité durable, pas une décoration.

Un socle technique en bonus.

Le vrai prix : du temps, mais aussi un peu d'argent

Pour rester honnête sur l'accounting : le projet n'a pas été 100 % gratuit. Vercel et Supabase ont basculé sur leurs tiers payants dès que mon usage a dépassé les seuils gratuits. Et environ deux cents dollars de Claude Code sur les deux semaines les plus intenses du chantier.

À nuancer immédiatement : ces outils servent aussi mes autres projets, la plateforme de formation, des chantiers clients, le pipeline de contenu. L'addition n'est donc pas 100 % attribuable à la refonte de ce site. C'est un coût mutualisé qui produit de la valeur ailleurs.

Une refonte équivalente confiée à une agence m'aurait coûté plusieurs dizaines de milliers d'euros, plus les frais récurrents. Là, l'addition reste sur des ordres de grandeur compatibles avec un budget solo, à condition d'avoir le temps. C'est principalement ce que j'ai payé.

Le vrai prix de la refonte.

[Unsupported MDX element: a]

Le parallèle avec la fonction achat indirecte

J'écris cet article parce que cette expérience a directement reconfiguré la façon dont je conseille mes clients sur la digitalisation de leur fonction achat.

La promesse du vibe coding pour les équipes achats, telle qu'on l'entend dans les conférences en ce moment, c'est : « vos acheteurs vont construire eux-mêmes leurs outils en quelques heures ». C'est partiellement vrai et largement trompeur, exactement de la même façon que mon « deux jours » est devenu plusieurs semaines.

Ce qui est vrai : un acheteur capable de cadrer un besoin fonctionnel précis peut désormais produire un outil utile sans passer par la DSI. Un analyseur de dépenses, un comparateur de devis, un simulateur de TCO, un générateur de RFP. Le code n'est plus la barrière.

Ce qui est faux : que cet outil sera fiable, maintenable, intégré au SI, conforme aux exigences cyber et aux contraintes RGPD, sans qu'un travail sérieux soit fait en parallèle du vibe coding. Le code représente peut-être 30 % du travail réel. Les 70 % restants, gouvernance des données, intégration aux systèmes existants, tests, sécurité, conformité, maintenance long-terme, n'ont pas disparu. Ils ont juste été rendus invisibles dans les démos.

Pour une direction achat d'ETI, le vrai sujet n'est pas « faut-il faire du vibe coding » mais « comment cadrer son usage avant que les équipes ne s'en emparent en shadow-IT ». Parce qu'elles vont s'en emparer. C'est trop facile pour qu'elles ne le fassent pas. La question est de savoir si c'est encadré ou subi.

La répartition du travail réel, vue côté achats.

Les limites de mon témoignage

Mon site est un site vitrine plus une plateforme de formation à charge légère. Ce n'est pas un système transactionnel, ce n'est pas un ERP, ce n'est pas un outil portant des engagements financiers automatisés. Le coût d'une erreur chez moi est ma propre frustration et quelques jours de SEO perdu. Le coût d'une erreur sur un outil achat connecté à votre P2P est d'un ordre de grandeur supérieur.

Mon expérience est aussi celle d'un solo opérateur qui contrôle tout de bout en bout. Une équipe achat dans une ETI travaille dans un environnement où la gouvernance, l'IT, la cyber, et les RH ont chacune leur mot à dire. Le récit « je l'ai fait tout seul en X jours » ne se transpose pas.

Et je n'ai pas encore six mois de recul sur la maintenance long-terme, sur la dette technique générée par l'IA, sur les coûts cachés quand les modèles évoluent et que ton code commence à dépendre d'une version qui change. Ce sont des sujets ouverts. J'y reviendrai quand j'aurai des données à partager.

Ce que je retiens

La barrière d'entrée pour produire un outil fonctionnel a chuté. La barrière d'entrée pour produire un outil robuste et économique en environnement professionnel, beaucoup moins. Confondre les deux est l'erreur la plus coûteuse que je vois venir dans les fonctions achat qui découvrent ces outils.

Pour un solo, un acheteur curieux, une PME qui veut un outil interne léger : le vibe coding est probablement l'un des leviers de productivité les plus sous-exploités du moment, à condition d'accepter le coût en temps qui accompagne la liberté retrouvée.

Pour une direction achat d'ETI ou de groupe : c'est un sujet à cadrer maintenant, pas dans dix-huit mois quand les premiers shadow-tools générés par les équipes commenceront à poser des questions de conformité, de sécurité, et de coût total de possession.

Le bon réflexe n'est pas de l'interdire. Le bon réflexe est de l'organiser, avec lucidité sur ce que ces outils livrent vraiment, et sur ce qu'ils ne livrent pas.

Le bon réflexe pour les directions achats.

Suite et mode d'emploi dans le Part 2.

Alex Lio accompagne les directions achats d'ETI françaises et de filiales germano-suisses sur la transformation de la fonction achat indirecte. Plus d'informations sur theprocurementor.com.