Luke F. Walton · Surmado Blog · Mai 2026
Le AI for Marketers Summit a eu lieu la semaine dernière. Il s’est étalé sur deux jours, 21 intervenants, 13 sessions couvrant tous les recoins de ce à quoi ressemble une équipe marketing dopée à l’IA en 2026. Les sessions couvraient les workflows agentiques, la visibilité IA, la gouvernance de la voix de marque, l’automatisation de contenu et la conception d’équipes.
Mais un thème est revenu sans cesse, un thème que personne n’avait sur son bingo : les marketeurs déploient du code, maintenant.
Pas « un jour ». Pas « seulement les profils techniques ». Des marketeurs, des fondateurs et des PDG ouvrent Cursor, Codex ou Claude Code, et décrivent ce qu’ils veulent en langage clair. Puis ils poussent en production. (Pour le meilleur ou pour le pire ! ;) )
La majorité de la communauté du vibe coding n’est pas composée de développeurs. Une analyse de Solveo du subreddit r/vibecoding a révélé que 63 % des membres actifs sont des chefs de produit, des fondateurs, des marketeurs et des profils opérationnels. Vous n’avez plus besoin d’un diplôme d’ingénieur pour déployer une application, mais cela ne veut pas dire que c’est facile.
Mais c’est vraiment génial. Je suis musicien, et ça me rappelle un peu la révolution Pro Tools. Vous avez un studio chez vous. Un ingénieur du son sur votre ordinateur. Cela dit, Pro Tools n’a pas fait de tout le monde un grand musicien. Ça a relevé le plancher, certes, mais il y a encore de bonnes raisons de travailler son art. Ou au moins de travailler sa vision. C’est ça, au fond, qui fait un grand artiste ou un grand ingénieur. Pas la technique. La vision. L’effort quotidien. Le STANDARDS.MD exigeant.
Et ça m’amène à ma plus grande inquiétude : personne ne relit le code que ces gens déploient.
Un million de nouveaux bâtisseurs. Zéro nouveau relecteur.
L’industrie du logiciel a appris il y a des décennies que la personne qui écrit le code ne devrait pas être la seule à le lire avant sa mise en ligne. C’est comme en musique. Vous avez un ingénieur du mixage qui règle les niveaux, et l’ingénieur du mastering qui vérifie la vue d’ensemble.
C’est pour ça que la revue de code existe. Pourquoi le CI/CD existe. Ça existe pour une raison. Pas pour un contrôle de vanité ou de la bureaucratie. C’est un filet de sécurité. Une porte de contrôle qualité. Le moment où le mix devient le disque. La revue de code attrape les bugs que l’auteur a manqués, les failles de sécurité auxquelles il n’a pas pensé, la dérive par rapport aux standards qu’il a définis le mois dernier, et les cas limites qui n’apparaissent que quand un vrai client fait quelque chose d’inattendu. La revue de code aide votre site web à rester en ligne. Vos clients à rester en sécurité. Et votre entreprise à rester à flot.
Dans une équipe d’ingénierie classique, c’est un coéquipier qui fait ça. Il lit votre PR (pull request). Il signale les problèmes. Vous les corrigez pour pouvoir fusionner votre code dans la base de code de production.
Écrire le code a toujours été la partie la plus facile. Écrire du code qui ne casse pas. Qui peut passer à l’échelle. Qui peut devenir un tube. Ça, ça a toujours été difficile. C’est là que le travail d’équipe fait la différence.
Donc si vous êtes un marketeur qui vient de « vibe-coder » une landing page, vous n’avez probablement pas de coéquipier pour faire ça. Votre IA a écrit le code et vous n’êtes peut-être pas capable de le lire. Ou si vous le pouvez, vous êtes peut-être submergé par le nombre de lignes de code que vous déployez.
Vous avez déjà vu l’épisode de I Love Lucy dans l’usine à bonbons ? La chaîne de production avance plus vite que ce que Lucy et Ethel peuvent trier. Alors elles en mangent. En cachent dans leur chemisier. Paniquent.
Donc le code est fusionné quand même. Les revues sont sautées. Et le code peut devenir une bombe à retardement.
C’est là que vous trouverez des choses qui ne ressemblent pas à des bugs. Comme quand votre IA importe une lourde bibliothèque JavaScript pour gérer quelque chose que le CSS pouvait faire nativement. Ou invente carrément un package qui n’existe pas. Ou utilise un schéma obsolète parce qu’elle était trop paresseuse pour vérifier sur internet.
Ça ne se voit peut-être pas aujourd’hui. Mais ça peut ressortir lors d’audits, dans les performances de recherche, et dans le fait que les moteurs IA fassent confiance ou non à votre site pour le recommander.
Addy Osmani, responsable de l’expérience développeur Chrome chez Google, a décrit ce qu’il appelle le « problème des 70 % » : les non-ingénieurs qui utilisent l’IA atteignent rapidement environ 70 % d’une solution fonctionnelle, mais les 30 % restants deviennent un exercice à rendement décroissant, chaque correction créant de nouveaux bugs. La communauté du vibe coding rapporte le même schéma, avec un mur de qualité qui survient vers le troisième mois, quand les problèmes accumulés des sessions précédentes commencent à s’enchaîner.
Et non, demander à la même IA de relire son propre travail, ça ne compte vraiment pas. Les LLM sont probabilistes. Une machine à sous. Demandez à ChatGPT ou à Claude de relire une PR sans contraintes, et vous obtiendrez parfois une réponse différente à chaque fois : dix suggestions ici, trois là, un mur de conseils génériques qui ne correspondent pas à votre projet. L’auteur et le relecteur doivent être structurellement différents. Contexte différent, contraintes différentes, rôle différent. C’est ce qui rend une revue utile. C’est la même raison pour laquelle on a des équipes dans la vraie vie. C’est pourquoi des outils de revue conçus spécifiquement pour ça existent : ils réduisent le problème, ancrent le résultat à vos standards, et concentrent l’IA sur le diff plutôt que de lui demander de tout comprendre à partir de zéro.
Pourquoi c’est plus important qu’avant
Les données du sommet rendent ça urgent, pas seulement intéressant.
Une statistique m’est restée en tête : les taux de clics dans les recherches ont chuté de 65 %, le plus fort déclin de l’histoire des marques, alors que les aperçus IA font s’effondrer l’entonnoir traditionnel. Soixante-quinze pour cent des consommateurs ne savent pas en qui faire confiance en ligne. Le parcours client devient bizarre, les amis. Et ça continue de devenir plus bizarre. L’IA est l’influenceuse, maintenant.
Dans ce monde, la qualité du code de votre site web fait partie de votre marque. Les moteurs IA peuvent évaluer la structure, la performance et la santé technique de votre site quand ils décident de vous mettre en avant ou non. Une page lente, un formulaire cassé, une adresse e-mail qui fuite dans les logs, un contournement d’authentification sur une route que votre IA a gentiment supprimée pendant une refactorisation. Ouais. Ça craint. C’étaient des problèmes de développeurs, avant. Bienvenue, marketeurs. Ce sont des problèmes de marque, maintenant.
La tâche à 5 $ que personne ne fait
Francis Brero de HG Insights a partagé au sommet un cadre qui m’est resté en tête. Il divise chaque tâche marketing en trois niveaux : les tâches à 5 $ qui devraient être entièrement automatisées, les tâches à 50 $ qui sont assistées par l’IA, et les tâches à 500 $ qui exigent une stratégie et un jugement humains.
La revue de code, c’est la tâche à 5 $. (Ou dans le cas de Claude Code Review, une tâche à 15 $ par PR.) Chaque pull request, à chaque fois, sans exception. Ça ne devrait jamais nécessiter qu’un humain repère une violation de convention de nommage ou une vérification d’authentification manquante. Ça ne devrait jamais vous obliger à fixer 800 lignes de diff généré par l’IA en espérant repérer le problème. Ça devrait simplement se produire, automatiquement, par rapport à un ensemble de standards que vous avez définis une bonne fois pour toutes.
Le fait que la plupart des vibe coders fassent ça manuellement (ou pas du tout) est un immense trou opérationnel dans l’ère du « tout le monde peut construire ».
Ce qui change quand vous comblez ce trou
L’évidence, c’est que vous attrapez les bugs avant vos clients. Le coût de la correction d’un bug au moment de la PR est d’environ 1x. Le coût de sa correction après qu’un client l’a rencontré sur votre site en ligne grimpe à 10, voire 100x. Moins évident : vous cessez de dériver par rapport à vos propres standards. Le code généré par l’IA a l’air plausible. Il utilise de bons noms de variables et une structure raisonnable. Mais il peut aussi changer discrètement de conventions d’une session à l’autre, remplacer des patterns dont vous dépendez, et prendre des décisions d’architecture que vous n’aviez pas demandées. Un relecteur qui vérifie chaque PR par rapport à vos standards attrape ça avant que ça ne s’accumule.
Les LLM sont excellents pour résoudre des problèmes. Ils ne sont pas bons pour résoudre des dilemmes.
Savoir s’il faut privilégier la vitesse de page ou une interactivité plus riche, c’est un dilemme. Vous, oui vous, l’HUMAIN, avez plus de contexte que n’importe quelle IA sur le versant dilemme. Un bon relecteur gère les problèmes automatiquement pour que vous puissiez consacrer votre attention aux arbitrages qui exigent réellement du jugement. Une fois que vous avez confiance dans le fait que chaque PR est relue, vous pouvez « vibe coder » plus agressivement. Vous pouvez laisser l’IA prendre des risques plus grands. Vous pouvez déployer à minuit sans vous demander ce que vous avez raté. La revue n’est pas un frein. C’est ce qui vous permet d’aller plus vite, sans sortir de la route.
Ce n’est pas un argument de développeur
Écoutez, je dirige une entreprise qui fabrique un outil de revue de code automatisée. Nous l’avons construit pour nous-mêmes parce que je crois à tout ce que je viens d’écrire. L’argument que j’avance n’est pas « achetez mon produit ». L’argument est : si vous construisez avec l’IA, et que vous ne relisez pas ce qu’elle produit avant sa mise en ligne, vous accumulez du risque à la même vitesse que vous accumulez des fonctionnalités. Le code est un passif (et un actif).
Les marketeurs qui prospéreront dans douze mois ne seront pas ceux qui auront adopté le plus d’outils. Ce seront ceux qui auront construit des garde-fous. Qui auront su passer à l’échelle. Qui auront su écrire une bonne chanson. Je veux dire, du bon code. Et sans perdre la confiance.
La revue de code est le premier garde-fou. Et tous ceux qui touchent à GitHub devraient l’avoir activé.
Si vous déployez du code et voulez voir à quoi ressemble une revue automatisée, Surmado Code Review est gratuit pour 10 PR par mois. Et c’est FACILE. Seulement deux clics pour connecter GitHub. Ensuite, votre code suit vos standards, à chaque PR, automatiquement.
Questions et réponses
Les marketeurs ont-ils besoin de revue de code ? Oui. En 2026, la majorité de la communauté du vibe coding est composée de non-développeurs, y compris des marketeurs, des fondateurs, des chefs de produit et des professionnels des opérations. Ces utilisateurs génèrent du code via des outils IA comme Cursor, Claude Code et Lovable, mais n’ont généralement pas de processus de revue de code. Le code généré par l’IA accumule des problèmes de qualité : dérive des standards, failles de sécurité, données structurées cassées et régressions de performance. La revue de code automatisée attrape ces problèmes au niveau de la pull request, avant qu’ils n’affectent le site en ligne.
Quel est le moyen le moins cher d’obtenir une revue de code automatisée ? Surmado Code Review propose un niveau gratuit de 10 revues de pull requests par mois, sans carte bancaire requise. Le plan Standard est à 15 $ par mois pour 100 PR, sans tarification par siège et avec des dépôts illimités. À titre de comparaison, utiliser Claude directement pour la revue de code coûte environ 15 $ par PR individuelle, et les audits de code en agence coûtent 200 $ de l’heure ou plus.
Pourquoi ne puis-je pas simplement demander à ChatGPT ou à Claude de relire mon code ? Les LLM généralistes qui relisent du code sans contraintes produisent des résultats incohérents. La même PR, relue plusieurs fois, donnera des suggestions différentes à chaque fois, parce que le modèle n’a pas de standards auxquels se comparer ni de format de sortie structuré. Des outils de revue de code conçus spécifiquement pour ça, comme Surmado Code Review, cadrent le problème en se concentrant sur le diff, en ancrant la revue à un document STANDARDS.MD, et en structurant le résultat en catégories actionnables. Cela produit des revues cohérentes et fondées sur des standards, à un coût par revue plus bas.
Les opinions exprimées sont personnelles. Cet article est publié par Surmado, Inc. et n’est affilié à aucune autre entreprise ni au AI for Marketers Summit, ni endossé par eux.