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

Si le site de votre entreprise est lent, difficile à mettre à jour ou dépend d’un développeur pour la moindre modification, le problème dépasse la technologie. Cela freine votre capacité à partager vos idées, présenter vos services et répondre à vos clients.

Comme beaucoup de petites et moyennes entreprises, nous avions externalisé le développement et la maintenance de notre site. À force de pages lentes et de mises à jour qui prenaient des semaines, voire des mois, j’ai fini par prendre moi-même en charge sa refonte.

À travers l’exemple du site de notre propre entreprise, cet article présente notre expérience de la refonte d’un site de PME avec l’IA : ce que nous avons changé, ce qui est devenu plus rapide et les aspects pour lesquels l’accompagnement humain restait indispensable. J’ai consacré environ 60 heures au développement et à la revue du travail, en utilisant Codex, Next.js, Payload CMS et les maquettes de notre designer dans Figma.

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 de l’entreprise, je discute régulièrement avec nos clients, étudie leurs besoins, suis les tendances de Salesforce et du CRM et échange des idées techniques avec nos ingénieurs.

Par exemple, une discussion interne sur Salesforce Data 360, son architecture ou ses cas d’usage possibles pouvait faire émerger des observations techniques intéressantes.

Ce qu’un ingénieur aurait pu partager directement devait passer par plusieurs personnes avant de pouvoir être publié.

Le problème venait en partie du fait que nous investissions peu dans notre site. Nous faisions appel à un développeur indépendant à temps partiel pour sa maintenance et ses mises à jour, mais cette organisation ne fonctionnait pas.

C’est là que j’ai commencé à repenser à un dicton bien connu :

Si vous voulez que les choses soient bien faites, faites-les vous-même.

Je trouve cette expression particulièrement pertinente dans une approche de relation directe avec le client.

Car nous sous-estimons souvent le nombre d’étapes, de personnes et de processus qui séparent les clients des personnes qui réalisent effectivement le travail.

Par combien d’étapes intermédiaires le problème d’un client passe-t-il avant d’arriver à un ingénieur ? Et combien d’autres faut-il encore pour que les connaissances ou la solution de cet ingénieur parviennent au client ?

Chaque étape supplémentaire crée de la distance entre les personnes qui rencontrent les problèmes et celles qui peuvent les résoudre.

Et je pense que l’IA est précisément la technologie qui peut contribuer à réduire cette distance.

Non pas en remplaçant les ingénieurs, les responsables de compte ou d’autres spécialistes, mais en supprimant les étapes intermédiaires inutiles et les tâches répétitives.

Ainsi, les personnes qui assurent réellement les prestations peuvent travailler au plus près des clients, comprendre directement leurs besoins et leurs difficultés et leur répondre sans passer par de multiples niveaux de communication.

L’IA devrait rapprocher la réalisation du client, et non ajouter un intermédiaire entre les deux.

Et c’est ce que je voulais obtenir avec notre site.

Reprendre la main, malgré PHP

J’ai décidé de mettre de côté mes anciennes réserves sur le micromanagement et de prendre moi-même en charge le site.

Il y avait juste un problème.

Mon parcours en génie logiciel ne m’avait jamais vraiment amené à travailler avec PHP.

J’ai toujours essayé de l’éviter autant que possible. Pour moi, c’est un peu une hérésie ou un blasphème. À mes yeux, ce n’est même pas un langage de programmation.

Bien sûr, j’exagère. Beaucoup de personnes aiment PHP, et il est largement utilisé pour les sites web.

Mais je crois que je suis tout simplement trop jeune pour les problèmes de PHP. Pour le développement web, mon cœur a toujours plutôt penché pour Node.js ou la stack .NET.

J’ai tout de même décidé d’examiner ce que nous avions.

Première tentative : corriger 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.

Des sections similaires avaient été développées par différentes personnes, avec des approches et des avis différents sur leur fonctionnement.

Le même problème se retrouvait visuellement. Des composants remplissant la même fonction avaient une apparence différente selon les pages, avec des couleurs, des bordures et des espacements incohérents.

Avec notre designer, nous avons décidé d’unifier les styles et les composants du site. Mais je voulais d’abord remettre le code existant dans un état raisonnable.

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.

14 octobre : le site est tombé en panne

Entre le 10 et le 14 octobre, je ne travaillais pas activement sur le site, mais je continuais à surveiller de temps en temps 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.

Notre équipe mettait à jour les listes d’adresses IP autorisées, ajustait les configurations réseau et appliquait d’autres correctifs temporaires.

Mais cela ne résolvait pas le problème à long terme.

Et, honnêtement, je n’avais pas envie de continuer à entretenir toute une infrastructure autour d’un plugin de traduction.

À un moment, c’est devenu tellement agaçant que j’ai probablement développé une sorte de psychose et décidé de recréer tout le site à partir de zéro.

Au lieu de réparer un énième plugin WordPress, j’ai décidé de remplacer WordPress lui-même.

Et PHP avec.

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

Le 14 octobre, j’ai donc commencé à reconstruire le site.

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 14 au 23 octobre, j’ai consacré environ quatre heures par jour ouvré à cette deuxième phase, soit environ 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.

Je ne travaillais pas avec un seul agent chargé de tout faire.

J’utilisais plusieurs agents pour différentes tâches et j’ai créé des skills réutilisables pour le déploiement du site.

Ces skills contenaient des instructions sur les scripts de déploiement à utiliser, les tests à exécuter et la manière de gérer les différentes étapes du processus.

Pendant le développement, les agents ont également créé des outils et des scripts pour tester et déployer le site.

Au lieu de réexpliquer toute la procédure de déploiement à chaque fois, je pouvais donc réutiliser les mêmes instructions et les mêmes processus.

Pour la validation, je me suis beaucoup appuyé sur Git afin de suivre les modifications et d’examiner ce qui se passait réellement dans le code.

En consultant les différences dans Git et en examinant les modifications fichier par fichier, je pouvais repérer le code dupliqué, les motifs répétés, les branches inutiles ou les instructions if-else compliquées.

Dès que je remarquais ce genre de problème, je demandais à l’agent de le corriger.

L’approche architecturale était principalement définie par Payload CMS et Next.js. Je voulais donc que les agents suivent les conventions de ces frameworks plutôt que d’inventer une architecture entièrement nouvelle.

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.

Je vérifiais manuellement l’interface, regardais le rendu des pages, testais les composants et repérais les problèmes visuels qui ne ressortent pas forcément d’une simple revue de code.

Dans ce cas, je jouais à la fois les rôles de développeur, de relecteur de code, de testeur manuel et de responsable de l’assurance qualité.

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.