Si vous voulez que les choses soient bien faites, faites-les vous-même. Avec l’IA.

Notre site se charge désormais en moins d’une seconde. À la vitesse de l’éclair.

Plus tôt cette semaine, le 21 octobre, nous avons mis en ligne notre site entièrement reconstruit. Mais les performances n’étaient pas la seule raison de cette refonte.

Il y a plusieurs difficultés dans lesquelles presque toutes les petites entreprises et équipes marketing se reconnaîtront.

Et bien sûr, vous voulez publier au plus vite, apporter des modifications en cours de route et ajuster les choses lorsque le résultat ne correspond pas à ce que vous aviez imaginé. Vos modifications peuvent facilement passer au deuxième ou au troisième plan. Un comportement inattendu du site, la complexité technique ou le besoin de fonctionnalités supplémentaires peuvent retarder la mise en ligne et laisser vos idées bloquées dans la liste des tâches en attente.

Notre ancien site était lent, peu pratique et difficile à maintenir. Nous avions accumulé de nombreuses améliorations de l’interface et des composants incohérents. Traditionnellement, une telle refonte se ferait par étapes : migrer le site existant, harmoniser les composants, puis introduire un nouveau design. Mais malgré les centaines de pages, nous avons décidé de tout faire d’un seul coup.

Alors, comment avons-nous laissé WordPress et PHP derrière nous pour passer à quelque chose de plus élégant, plus rapide et plus moderne, avec une petite touche de pumpkin spice latte ? Voici un retour sur notre parcours vers Next.js et Payload CMS, pendant que notre designer travaillait sur une nouvelle UI/UX et que Codex prenait en charge la génération de code, l’implémentation et le déploiement.

Le problème ne se limitait pas au site

Pendant environ un an, j’avais toléré les problèmes de notre site, tant techniques qu’opérationnels.

Mais le plus gros problème était la difficulté à transmettre directement nos connaissances et nos idées à des clients potentiels.

En tant que dirigeant et fondateur, j’échange régulièrement avec les clients, je cherche à comprendre leurs besoins et je participe aux sessions d’architecture des solutions techniques avec notre équipe d’ingénieurs.

Nos ingénieurs travaillent directement avec les clients. Ils connaissent les problèmes qu’ils rencontrent, savent ce qui pourrait améliorer leur activité et ont souvent d’excellentes idées à partager. Il en va de même pour notre équipe commerciale, qui échange constamment avec les clients et identifie leurs difficultés et leurs besoins.

La question est la suivante : comment raccourcir la distance entre ces idées et le client tout en préservant la vision et les intentions initiales de l’auteur ?

J’ai compris que l’IA pouvait nous aider à supprimer ces étapes intermédiaires inutiles.

Et les modifications qui prenaient auparavant une journée peuvent désormais ne prendre que quelques minutes.

Cet article en est lui-même un bon exemple. Je dicte mes réflexions, qui ne sont pas toujours très structurées. Puis je lis le résultat, je le relis, je déplace des paragraphes, je précise la description des problèmes ou je demande simplement : « Présente ces problèmes dans des blocs distincts sur la page. »

C’est cette expérience que je voulais créer : un site où les personnes qui maîtrisent réellement le sujet peuvent communiquer directement leurs idées, les affiner immédiatement et publier sans passer inutilement le relais à d’autres.

L’IA devrait rapprocher du client les personnes qui font le travail, et non ajouter une couche intermédiaire entre eux.

La partie ennuyeuse : améliorons ce que nous avons déjà

J’ai commencé à travailler sur la transformation du site le 1er octobre 2026.

Ma première idée était simple : nettoyer le site existant, refactoriser le code, supprimer les duplications inutiles et améliorer les performances.

Mais je ne pouvais pas produire des tonnes de code en peu de temps, alors j’ai décidé d’utiliser Codex.

J’ai examiné le code PHP et constaté que presque tous les modèles de page présentaient d’importants problèmes de duplication.

Avec Codex, j’ai pu extraire des composants réutilisables, éliminer les duplications entre les pages, réduire le volume de code et améliorer les performances.

Et ce qui est intéressant, c’est que les prompts étaient assez simples.

Par exemple :

Prends cette section, [indique l’ID de la section dans la page HTML affichée], remplace-la et extrais-en un composant réutilisable. Vérifie toutes les autres pages du site et remplace les implémentations correspondantes par la nouvelle. Veille ensuite à supprimer tout le code ancien et inutilisé, puis valide ton travail.

C’était à peu près tout.

Au passage, j’ai découvert pas mal d’autres problèmes.

Par exemple, certaines icônes du menu de navigation affichées en 32 pixels étaient en réalité des fichiers image d’environ un mégaoctet chacun.

Imaginez charger une image d’un mégaoctet pour afficher une minuscule icône de navigation.

J’ai donc demandé à Codex :

Prends [image], analyse-la, augmente sa résolution si nécessaire et convertis-la au format WebP. Optimise-la pour accélérer le chargement de la page, redimensionne-la aux dimensions réelles d’affichage (par exemple, 32 × 32 pixels) et réduis autant que possible la taille du fichier sans compromettre la qualité visuelle.

Nous avons répété cette opération sur l’ensemble du site, en remplaçant les images inutilement volumineuses et en nettoyant le code.

Et cela a fonctionné.

C’était plutôt impressionnant.

J’ai travaillé sur cette première phase du 1er au 10 octobre, à raison d’environ quatre heures par jour ouvré, hors week-ends.

Cela représente environ 28 heures consacrées au nettoyage du code PHP et à l’optimisation de notre site WordPress existant.

À ce stade, je pensais en avoir terminé avec les modifications techniques.

Il ne restait plus qu’à laisser notre designer terminer les nouveaux styles, et nous pourrions avancer.

J’ai donc fait une pause dans le développement actif.

Mais la situation s’est dégradée de manière inattendue.

Incident du 12 octobre : le site est devenu inaccessible

Entre le 10 et le 12 octobre, je ne travaillais pas activement sur le site, mais je continuais à surveiller de temps à autre les métriques de notre serveur.

Au début, j’ai pensé que mes récentes modifications pouvaient en être la cause.

J’ai donc commencé à enquêter et utilisé ChatGPT pour examiner en profondeur le site existant et la configuration du serveur.

Mes recherches indiquaient que le problème ne semblait pas venir de mes modifications de code.

Le site était hébergé sur un serveur doté de 2 Go de RAM et de deux CPU, ce qui me paraissait suffisant pour notre site.

Je ne dis pas pour autant que GTranslate est un mauvais produit.

Le problème provenait probablement d’une combinaison de plusieurs facteurs dans notre infrastructure. Le plugin nécessitait une maintenance active et des ajustements de notre part pour que tout continue à fonctionner correctement.

Je savais que le problème pouvait réapparaître. Nous avions aussi un bon nombre de plugins dont le rôle consistait essentiellement à éviter d’écrire du code pour des fonctionnalités relativement simples, comme les formulaires de contact, les traductions et plusieurs autres fonctions.

Beaucoup de ces plugins pouvaient facilement être supprimés ou remplacés, idéalement en confiant leurs fonctionnalités directement à un nouveau CMS.

Et si nous voulions assurer nous-mêmes la maintenance et le support de notre site, il était logique d’abandonner PHP pour une technologie que tout développeur Salesforce connaît par cœur : JavaScript.

C’est pourquoi nous avons choisi Node.js côté serveur.

Reconstruire avec Node.js, Next.js, React et Payload CMS

J’ai donc commencé à reconstruire le site le 12 octobre.

Je voulais réduire notre dépendance aux plugins et créer une plateforme unifiée avec un système de gestion de contenu, des traductions intégrées et une structure que je pouvais maîtriser.

Je suis à l’aise avec JavaScript et Node.js et j’avais déjà réalisé plusieurs projets avec ces technologies.

Pourquoi Payload CMS ?

Parce qu’il repose sur Next.js et que Next.js me semblait être une très bonne option.

Je voulais pouvoir travailler avec une stack technologique familière, sans introduire un nouvel ensemble d’outils et de dépendances.

Payload et Next.js nous offraient aussi une base architecturale cohérente, ce qui m’évitait de tout inventer à partir de zéro.

Et oui, j’ai été tenté de simplement dire à l’agent :

Réécris l’intégralité du site WordPress avec la stack Node.js, Next.js, React et Payload CMS que je souhaite utiliser. Fais-le correctement, fais-le bien, valide tout, utilise des sous-agents et ne me dérange pas.

Mais j’ai dû procéder autrement.

La première version alpha était essentiellement une migration à l’identique, à l’exception de la base de données.

Nous avons introduit plusieurs nouvelles entités et réorganisé la gestion du contenu. Je voulais que l’expérience dans le CMS se rapproche de celle de Pipedrive ou de HubSpot, avec la navigation à gauche et le contenu à droite.

Migrer le site existant

Un point important : nous ne créions pas l’intégralité du site à partir de zéro.

Nous avions déjà du contenu, des structures de page, des idées de design et des années de travail derrière nous.

Il s’agit en fait probablement de la quatrième grande version de notre site.

En 2019, nous avions commencé avec le thème WordPress Flaton. Nous avions même un autre logo à l’époque.

Plus tard, nous avons développé notre propre thème, l’avons mis à jour et avons continué à améliorer l’interface.

Notre designer travaillait également sur le dernier système de design avant le début de cette migration.

Il s’agissait donc d’une migration technique complète et d’une restructuration d’un site existant, et non de la création d’un produit entièrement nouveau à partir de zéro.

Pour migrer le contenu, nous avons tout extrait de WordPress et utilisé un agent IA pour l’adapter au nouveau modèle de base de données de Payload CMS.

L’agent a aidé à transformer le contenu pour l’adapter à la nouvelle structure, plutôt que de simplement le copier dans une autre base de données.

Nous avons aussi utilisé des agents pour déployer le nouveau site, basculer depuis l’implémentation PHP et supprimer les anciens fichiers PHP ainsi que leur configuration du serveur.

Était-ce l’approche la plus élégante ?

Probablement pas.

Mais pour nous, c’était le moyen le plus rapide de tout migrer et de tout faire fonctionner.

Corriger ce qui n’avait pas survécu à la réécriture

Une fois la réécriture initiale terminée, j’avais sous les yeux pratiquement le même site, avec seulement quelques petites différences.

Puis j’ai commencé à corriger les bugs.

À un endroit, un carrousel ne fonctionnait plus. Ailleurs, la mise en page était décalée. Certains composants ne se comportaient plus exactement comme avant.

En corrigeant ces problèmes, j’ai réalisé que tous les composants n’avaient pas été correctement remplacés.

Certains modèles de page contenaient encore du HTML brut, tandis que d’autres intégraient de nouveaux composants qui ressemblaient vaguement à des composants réutilisables que nous avions déjà.

J’ai donc commencé à repérer et répertorier ces endroits, puis à les traiter un par un.

Le prompt ressemblait à ceci :

Voici une section [indique le nom ou l’ID de la section]. Remplace-la par le composant réutilisable existant [indique le nom du composant]. Veille à conserver une sémantique et un comportement identiques ou similaires, supprime l’ancienne implémentation et nettoie le code inutilisé.

J’ai continué à remplacer les anciennes implémentations, à améliorer le rendu côté serveur, à introduire de la mise en cache et à optimiser les composants.

Du 12 au 23 octobre, j’ai consacré environ quatre heures par jour ouvré à cette deuxième phase, soit à peu près 32 heures au total.

Un agent crée, un autre vérifie, et un humain décide

Un autre aspect intéressant était ma façon d’organiser le développement et le déploiement.

Au lieu d’utiliser un seul agent pour tout, j’en ai créé plusieurs avec des responsabilités précises : l’un pour examiner l’ancienne implémentation, un autre pour recréer l’interface existante sur la nouvelle plateforme, d’autres pour valider l’implémentation et un dernier pour gérer le déploiement.

J’ai aussi créé des skills réutilisables contenant des instructions pour les scripts de déploiement, les tests et la validation, afin que les agents suivent les mêmes processus sans avoir à tout leur réexpliquer à chaque fois.

Ces skills contenaient des instructions pour se repérer dans notre système de design, réutiliser les tokens de design et travailler avec les frameworks nouvellement introduits.

Pourquoi des skills ? Parce qu’ils permettent aux agents de réutiliser les mêmes connaissances et instructions sans multiplier les agents très spécialisés pour chaque tâche.

Pour la revue du code, je m’appuyais beaucoup sur les diffs Git, en vérifiant les modifications pour repérer le code dupliqué, la complexité inutile et les implémentations incohérentes. Chaque fois que je trouvais un problème, je demandais aux agents de le corriger.

Puisque Next.js et Payload CMS proposent déjà des modèles d’architecture éprouvés, j’ai demandé aux agents de suivre ces conventions plutôt que d’inventer leur propre architecture.

J’ai aussi chargé d’autres agents de vérifier l’implémentation.

Le processus était assez simple :

Un agent crée, un autre vérifie, et un humain décide de ce qui est correct ou non.

Et l’humain regarde le site lui-même, pas seulement le code.

Nous vérifiions manuellement l’interface, examinions le rendu des pages, testions les composants et repérions les problèmes visuels qui ne sont pas forcément évidents à la seule lecture du code.

Environ 30 % de mon temps a été consacré à la revue du code, à la vérification des implémentations et à la validation des résultats.

J’ai aussi ajouté des vérifications par des agents avant le déploiement, afin de repérer les problèmes restants et de nettoyer le code laissé après les itérations successives.

Parce que l’IA génère des tonnes de code.

Et si personne ne fait attention à ce qu’elle produit, on peut facilement remplacer une ancienne dette technique par une nouvelle.

Traduire le site avec des agents IA

Les traductions constituaient un autre volet important de l’implémentation.

Auparavant, nous utilisions GTranslate pour traduire notre contenu en temps réel.

Cette fois, je voulais que les traductions soient gérées directement dans notre plateforme.

Nous avons utilisé un agent IA pour traduire notre contenu anglais dans toutes les autres langues du site.

Voici le prompt :

Tu traduis du contenu de l’anglais vers la [langue cible].

Analyse la version anglaise du contenu et identifie les noms de marques, les termes propres aux technologies, les noms de produits et les autres noms propres.

Assure-toi de comprendre l’intention d’origine et le sens exact du contenu avant de le traduire. Reste aussi proche que possible du sens et de l’intention d’origine, tout en respectant les règles linguistiques de la [langue cible].

Préserve les noms de marques, les noms de produits et la terminologie propre aux technologies lorsque cela est pertinent.

Après la traduction, vérifie ton travail pour t’assurer que le sens est préservé, que la langue est naturelle et qu’aucun contenu n’a été omis.

Veille à traduire tout le contenu, y compris le titre de l’article, les intertitres, le corps du texte et toutes les métadonnées associées.

L’objectif n’était pas simplement de traduire des mots. Je voulais que le contenu respecte les règles de chaque langue et paraisse naturel aux lecteurs locaux.

Nous avons également séparé les informations propres aux marques du contenu à traduire, afin que les noms d’entreprises, les noms de produits et les autres termes importants ne soient pas traduits à tort.

Nous pouvons désormais gérer les traductions directement dans notre CMS, sans dépendre d’un plugin qui traduit tout en temps réel.

Bien sûr, la traduction par IA n’est pas parfaite, surtout pour du contenu technique sur Salesforce, le CRM et le génie logiciel.

Si vous visitez notre site dans votre langue et remarquez une formulation peu naturelle, mal écrite ou incompréhensible, envoyez-moi simplement un message privé.

Je m’en occuperai.

Quand Figma, Codex et GPT-6 se sont rencontrés

Pendant ce temps, notre designer a terminé le nouveau système de design dans Figma. Et c’est là que les choses sont devenues intéressantes.

Figma prend en charge l’intégration MCP, et nous utilisons déjà OpenAI avec Salesforce et d’autres plateformes. J’ai donc connecté Figma à mon compte OpenAI.

Je pouvais ainsi prendre le lien d’un élément Figma, qu’il s’agisse d’un bouton, d’une section ou d’un autre composant, et le transmettre à Codex utilisant GPT-6. Codex prenait le design et l’intégrait directement à notre site.

Grâce au travail préalable d’extraction des composants réutilisables, il pouvait appliquer le nouveau système de design sur toutes les pages, au lieu de reproduire les mêmes modifications séparément partout. Au lieu d’écrire manuellement le CSS et d’ajuster chaque marge intérieure, rayon de bordure ou disposition de composant, je pouvais faire intégrer dans le code le travail de notre designer dans Figma.

Bien sûr, ce n’était pas entièrement automatique. Je devais encore vérifier le code, la structure HTML, le comportement des composants et les endroits où OpenAI avait pu prendre un raccourci ou mal comprendre les exigences.

En moyenne, chaque composant nécessitait environ deux itérations.

C’est là que j’ai concentré l’essentiel de mon attention.

Ce que nous avons réellement obtenu

Grâce à la nouvelle implémentation Node.js, à la mise en cache, au rendu côté serveur et à d’autres optimisations, les pages se chargent désormais en moins d’une seconde en moyenne, contre environ cinq ou six secondes avant la transformation.

Nous avons étudié les métriques de performance du navigateur, notamment le rendu des pages, le Largest Contentful Paint et les décalages de mise en page, et utilisé des audits Semrush pour évaluer la santé du site, son explorabilité, sa navigation et d’autres aspects techniques.

Mais j’ai aussi évalué les performances d’une manière beaucoup plus simple.

Avec l’ancien site, les lenteurs étaient visibles, sur mobile comme sur ordinateur. Les pages mettaient du temps à se charger et l’expérience n’était pas particulièrement agréable.

Avec la nouvelle implémentation, la différence était immédiatement perceptible.

Le site paraît tout simplement nettement plus rapide.

Bien sûr, la perception visuelle ne remplace pas les mesures techniques, mais elle constituait pour moi un indicateur important, car c’est ce que vivent réellement les visiteurs.

Le nombre de problèmes techniques a lui aussi nettement diminué.

En septembre et en octobre, Semrush signalait environ 2 000 problèmes, avec des pics approchant les 3 000.

Nous en sommes maintenant à environ 400 problèmes, dont à peu près 200 sont liés au mécanisme de protection des adresses e-mail de Cloudflare, signalé comme des liens internes rompus.

Il reste des points à améliorer, mais par rapport à notre situation de départ, le contexte est complètement différent.

De la maintenance du site au contenu directement destiné au client

Les performances n’étaient pas la seule amélioration.

Nous avons aussi obtenu quelque chose de probablement encore plus important : une manière bien plus agréable de créer et de gérer le contenu.

Auparavant, modifier une page nécessitait que quelqu’un mette manuellement à jour les modèles, ajuste le contenu et réalise le travail technique.

Au lieu de passer par plusieurs personnes pour transformer notre expérience en contenu pour le site, nous pouvons gérer l’essentiel des tâches répétitives grâce à la plateforme.

L’ingénieur n’a pas besoin de devenir rédacteur. Le responsable de compte n’a pas besoin de devenir développeur. Et la personne qui a une idée ne devrait pas attendre des mois que quelqu’un la concrétise sur le site.

Il ne s’agit pas pour autant de produire du contenu artificiel et creux généré par IA.

Prenez cet article, par exemple.

Il n’est en fait pas rédigé manuellement. Les idées et les réflexions sont dictées, transcrites en texte, puis retravaillées.

Nous pouvons dire quelque chose comme : « Reformule ceci, rends ce passage plus agréable à lire, supprime les mots inutiles, emploie un ton plus poli. »

Mais les idées, l’expérience et le récit restent les nôtres.

L’IA nous aide à transformer nos réflexions en un texte lisible, tout comme elle nous a aidés à transformer notre design et nos exigences techniques en code concret.

Et c’est exactement le mode de travail que nous recherchions.

La même approche peut s’appliquer aux articles techniques, aux témoignages de réussite de nos clients, aux descriptions de services et aux autres contenus que nous souhaitons partager.

Auparavant, nous dépendions fortement des rédacteurs et des administrateurs du site pour transformer quelques mots d’experts techniques en articles complets.

Un expert technique passe quelques minutes à expliquer ce qu’il a fait, puis un rédacteur transforme cela en des milliers de mots.

De longs articles ambitieux, remplis de texte, d’explications et, assez souvent, de beaucoup de remplissage.

Pendant ce temps, l’ingénieur lui-même décrirait probablement le même projet en quelques phrases :

« Oui, on l’a fait. C’était facile. C’était intéressant. C’était sympa. »

Il mentionnera peut-être quelques bénéfices pour l’entreprise au passage. Même si un responsable de compte devrait probablement pouvoir les expliquer bien mieux.

Nous voulons que nos ingénieurs expliquent brièvement ce qui était intéressant dans l’implémentation, ce qui était techniquement difficile et ce qui était utile, puis retournent à d’autres travaux intéressants.

Plutôt que de passer des heures à tout décrire à quelqu’un qui finira par en faire un article.

C’est ce type de tâches répétitives que nous voulions éliminer.

Et c’est aussi ce que j’entends par rapprocher la réalisation du client.

L’IA peut aider à supprimer les tâches répétitives entre ces personnes et permettre aux connaissances de passer beaucoup plus directement de ceux qui les possèdent à ceux qui en ont besoin.

Temps de développement et coûts

Bien sûr, cela ne signifie pas que le site a été entièrement reconstruit pour 245 €.

Ce montant n’inclut ni mon temps, ni le travail de notre designer, ni l’infrastructure, ni les années d’investissement antérieur dans le site.

Nous développons et améliorons notre site depuis 2019, en changeant de thème, en faisant évoluer le design, en créant du contenu et en ajustant sa structure.

La dernière migration a réutilisé une grande partie de ce travail.

Mais ce qui est intéressant, c’est tout ce que j’ai pu accomplir avec environ 60 heures d’implication personnelle, en utilisant l’IA pour le développement, la refactorisation, les tests, le déploiement et la revue du code.

Ce qui a changé en pratique

La comparaison ci-dessous porte sur les délais calendaires de réalisation lorsque nous travaillions avec un développeur indépendant. Il ne s’agit ni de budgets de projet, ni d’une comparaison à périmètre égal des heures travaillées.

Par exemple, une page pouvait représenter environ 40 heures de développement, réparties sur plusieurs semaines de travail et d’améliorations continues.

Ces estimations commencent une fois l’idée et les exigences définies. La réflexion initiale et la définition des exigences sont des phases importantes à part entière, qui ne sont pas incluses ici.

Et ensuite ?

Les bases techniques sont désormais en place.

Nous disposons d’une plateforme que nous pouvons maintenir sans modifier manuellement chaque élément du site.

Bien sûr, nous pouvons toujours tout modifier directement si nous le souhaitons. Mais nous pouvons maintenant simplement dire à l’agent qui entretient notre site :

Ajoute [article], utilise [images], crée quelques infographies ou tableaux à partir de ce contenu et publie-le sous forme de [étude de cas ou article de blog].

Il en va de même pour la mise à jour des pages existantes.

Par exemple :

Prends cette page [indique l’URL ou le titre de la page], trouve cette section [indique le nom, le titre ou l’ID de la section] et mets-la à jour. Remplace l’image, actualise ou enrichis le texte selon mes instructions et veille à respecter notre système de design existant. Préserve les fonctionnalités du composant et valide les modifications.

Qu’il s’agisse de remplacer une image, d’enrichir la description d’un service, de publier un article ou de mettre à jour une section entière, nous pouvons expliquer ce que nous voulons obtenir, examiner le résultat et faire des ajustements si nécessaire.

Cela nous épargne des heures de tâches répétitives que nous pouvons consacrer au développement d’idées, à l’étude des besoins des clients et à la création de contenu utile.

Et oui, la situation est maintenant nettement meilleure sur pratiquement tous les plans.

L’infrastructure est en place. La plateforme est facile à maintenir. Il suffit d’expliquer ce dont vous avez besoin, et l’agent peut l’ajouter en quelques minutes. Le contenu est plus facile à publier et nous maîtrisons bien mieux le fonctionnement du site.

Nous pouvons désormais nous concentrer sur les idées plutôt que sur les contraintes techniques.

Mais le changement le plus important concerne notre manière de travailler avec nos clients.

Au lieu de séparer les ingénieurs, les responsables de compte, le marketing et les administrateurs du site par de multiples étapes et processus, nous pouvons rendre les échanges de connaissances bien plus directs.

Ceux qui comprennent les problèmes du client peuvent partager leurs connaissances, et ceux qui conçoivent les solutions peuvent entendre ce dont les clients ont réellement besoin.

La technologie n’était pas censée être le problème auquel nous consacrions le plus de temps.

Elle était censée nous aider à transmettre nos idées aux clients.

Et maintenant, enfin, la technologie n’est plus une source de difficultés.