L'IA ne remplacera pas votre agence web — mais elle a changé ce pour quoi vous payez

Ils allaient 19 % moins vite, et ils étaient certains du contraire

En juillet 2025, le laboratoire indépendant METR a publié le résultat d'un essai contrôlé randomisé qui aurait dû calmer beaucoup de discours commerciaux. Seize développeurs expérimentés, 246 tâches réelles — corrections de bugs, refactorings, ajouts de fonctionnalités — sur des dépôts open source matures qu'ils connaissaient bien. La moitié des tâches avec assistance IA, l'autre moitié sans.

Résultat : avec l'IA, ils ont mis 19 % de temps en plus. Et le plus intéressant n'est pas là. Interrogés après coup, ces mêmes développeurs estimaient avoir gagné 20 % de temps. Avant l'expérience, ils en attendaient 24 %. Des experts extérieurs en économie et en machine learning avaient prédit, eux, 39 % et 38 % de gain (METR, juillet 2025).

Personne ne mentait. L'écart entre la performance ressentie et la performance mesurée était simplement de 39 points.

Retenez ce chiffre, parce que c'est exactement celui qui vous concerne quand un prestataire vous annonce des délais divisés par deux « grâce à l'IA ». Il est probablement sincère. Cela ne veut pas dire qu'il a raison.

Ce que disent vraiment les chiffres

Le débat public oppose deux camps qui citent chacun une étude réelle. Les deux ont raison — sur des choses différentes.

La ligne de partage est nette : l'IA est spectaculaire sur du neuf sans contrainte, et handicapante sur de l'existant à contraintes. Or votre projet, sauf s'il démarre littéralement de rien, appartient à la seconde catégorie dès la deuxième semaine.

L'enquête Stack Overflow 2025 ajoute deux données que je trouve plus parlantes que les pourcentages de vitesse :

• •66 % des développeurs citent comme frustration n° 1 les solutions « presque justes, mais pas tout à fait ».
• •45 % constatent que déboguer du code généré par IA leur prend plus de temps que d'en écrire.

Le sentiment positif envers ces outils est passé de plus de 70 % en 2024 à 60 % en 2025. Ce n'est pas un rejet — c'est un dégrisement, par des gens qui les utilisent tous les jours.

Ce que l'IA fait très bien, et que j'utilise tous les jours

Je ne vais pas jouer l'artisan nostalgique : j'utilise ces outils quotidiennement et je ne reviendrais pas en arrière. Il y a trois usages où le gain est réel et non contesté.

Le code répétitif et prévisible

Formulaires, composants d'interface standards, requêtes de base, scripts de migration, tests unitaires sur des fonctions simples. Tout ce qui a été écrit dix mille fois avant vous. L'IA le produit en quelques secondes et correctement.

L'exploration et la lecture

Comprendre une bibliothèque inconnue, décrypter un message d'erreur obscur, parcourir une documentation de 400 pages pour trouver le bon paramètre. C'est là que le gain de temps est le plus franc, et il ne comporte quasiment aucun risque : je vérifie immédiatement si la réponse marche.

Le prototype jetable

Tester une idée d'interface en une heure pour voir si elle tient debout. C'est précieux en phase exploratoire, notamment sur un MVP de startup. La condition tient en un mot : jetable. Un prototype qui glisse en production sans être réécrit est la façon la plus courante de créer une dette technique invisible — j'ai détaillé ce mécanisme dans mon article sur les limites du vibe coding.

Les quatre limites que les démos ne montrent jamais

1. Le code générique ignore votre contexte

Un modèle ne connaît ni votre architecture existante, ni vos contraintes de charge, ni les décisions prises il y a six mois et les raisons qui les motivaient. Il produit une solution plausible en moyenne, pas la bonne solution pour vous.

En pratique, ça donne du code qui fonctionne à la démonstration et qui se fissure à la troisième fonctionnalité, parce que chaque morceau a été conçu isolément. La dette technique n'est pas une abstraction de développeur : c'est le devis de votre évolution suivante, multiplié par deux.

2. Aucune décision de périmètre

Demandez un outil de gestion à une IA : vous l'obtiendrez. Elle ne vous demandera jamais si vous en avez besoin.

Les questions qui décident du succès d'un projet ne sont pas techniques :

• •Quel problème coûte réellement de l'argent aujourd'hui, chiffré ?
• •Quelle métrique unique le produit doit-il faire bouger ?
• •Qu'est-ce qu'on refuse de construire, et qu'on assume de refuser ?
• •Qu'est-ce qui doit exister en version 1 pour qu'un utilisateur paie ?

C'est le travail que je fais avant d'écrire la moindre ligne, et c'est celui qui détermine si le budget sert à quelque chose. J'ai documenté cette démarche de bout en bout dans l'étude de cas d'Adhérence, le produit que j'ai conçu et que j'exploite.

C'est aussi la raison principale pour laquelle 95 % des projets d'IA en entreprise n'atteignent jamais la production : le problème n'était pas posé.

3. La sécurité par omission

Une IA ne produit pas du code volontairement vulnérable. Elle produit du code qui répond à la demande — et une demande ne contient presque jamais « et protège-moi des injections SQL, du XSS stocké, de l'escalade de privilèges et des fuites de données dans les logs ».

Pour une page de présentation, l'enjeu est faible. Dès qu'il y a des comptes utilisateurs, du paiement ou des données personnelles, vous êtes dans un domaine où l'omission a un coût réglementaire. Le guide cybersécurité PME détaille ce que ça implique concrètement.

4. Personne pour signer

C'est la limite dont on parle le moins et qui compte le plus. Quand le site tombe un vendredi soir, quand un client vous signale que ses données apparaissent dans le compte d'un autre, quand la CNIL pose une question : une IA ne répond pas de son travail.

Vous ne payez pas seulement une production. Vous payez quelqu'un qui engage sa responsabilité, son assurance et sa réputation sur le résultat. C'est précisément la partie que la génération automatique ne peut pas fournir, et c'est celle dont la valeur a le plus augmenté.

L'angle que personne ne vous vend : la taxe du « presque juste »

Voici le raisonnement que je fais rarement lire ailleurs, et qui explique le paradoxe de l'étude METR.

Quand un développeur écrit du code lui-même, il sait ce qu'il ne sait pas. Le doute est localisé : il connaît les trois endroits fragiles de son travail et il les teste.

Quand il relit du code généré, le doute est partout et nulle part. Le code est syntaxiquement propre, bien nommé, commenté. Il a l'air correct. Repérer l'erreur subtile — la condition inversée, le cas limite non traité, la variable réutilisée — demande de le lire aussi attentivement que si on l'écrivait, sans le bénéfice de l'avoir pensé.

C'est ça, la taxe du « presque juste » que 66 % des développeurs signalent. Le travail ne disparaît pas : il se déplace de l'écriture vers la vérification. Et la vérification est plus lente, plus fatigante, et moins facturable à l'heure.

Conséquence directe pour vous : le coût de produire du code qui a l'air de marcher s'est effondré. Le coût de garantir qu'il marche, non. Un prestataire qui répercute intégralement la baisse du premier poste sans investir dans le second ne vous fait pas une remise — il vous transfère un risque.

Les cinq idées fausses qui vont vous coûter cher

1. « L'IA a divisé les prix par deux »

Elle a divisé le temps de frappe, qui n'a jamais été le poste principal. Sur un projet d'application métier, l'écriture de code représente grossièrement un tiers du temps. Le reste, c'est le cadrage, la conception, les tests, les corrections, la mise en production et la reprise après vos retours. Un gain de 50 % sur un tiers, ce n'est pas une division par deux.

2. « Je vais le faire moi-même avec un outil no-code IA »

Vous pouvez, et pour certains besoins c'est le bon choix — j'ai écrit un guide honnête sur le no-code et le low-code qui dit exactement quand y aller. Le piège n'est pas au démarrage, il est à la reprise : le jour où l'outil ne fait pas ce dont vous avez besoin, vous découvrez que vous ne possédez ni le code, ni les données dans un format exploitable, ni un prestataire capable de reprendre le tout.

3. « Si mon développeur utilise l'IA, je me fais avoir »

Non — et exiger le contraire serait absurde. Vous achetez un résultat, pas une méthode de saisie. La bonne question n'est pas « utilisez-vous l'IA ? » mais « qui relit, qui teste et qui répond si ça casse ? ».

4. « Le code généré n'appartient à personne, donc c'est gratuit et sans risque »

Le statut juridique du code généré reste discuté et dépend du degré d'intervention humaine. Ce qui n'est pas discuté, en revanche, c'est votre responsabilité de donneur d'ordre vis-à-vis de vos utilisateurs et du RGPD. Faites écrire noir sur blanc dans le contrat que le code source vous est cédé et livré. C'est vrai avec ou sans IA, et c'est le premier point que je vérifierais à votre place.

5. « Google va de toute façon tout remplacer par de l'IA, le site ne sert plus à rien »

Les AI Overviews changent la façon dont les gens arrivent chez vous, pas le fait qu'ils y arrivent. Et la quasi-totalité des citations que produisent ces synthèses viennent de pages bien classées dans les résultats organiques : le référencement classique est devenu le prérequis de la visibilité dans l'IA, pas son concurrent. J'ai détaillé ce mécanisme dans ce que les AI Overviews changent pour votre site.

Comment décider, en 4 étapes

Étape 1 — Qualifiez l'enjeu avant de qualifier l'outil

Répondez à quatre questions par oui ou non : ce projet représente-t-il mon entreprise auprès de mes clients ? Doit-il être trouvé sur Google ? Traitera-t-il des données personnelles ou des paiements ? Devra-t-il évoluer au-delà de six mois ? Zéro « oui » : un outil génératif suffit probablement. Deux « oui » ou plus : vous achetez de la responsabilité, pas de la production.

Étape 2 — Testez l'IA sur votre cas réel, pas sur la démo

Prenez la fonctionnalité la plus spécifique de votre métier — celle qui fait que les logiciels du marché ne vous vont pas — et demandez-la à l'outil que vous envisagez. Les démonstrations utilisent toujours des cas génériques. Votre exception métier, elle, est exactement là où le modèle n'a rien à recopier.

Étape 3 — Faites auditer les fondations avant la mise en production

Si un prototype généré vous convainc, ne le mettez pas en ligne tel quel : faites relire l'authentification, la gestion des droits, le traitement des données personnelles et la sauvegarde. C'est une intervention courte et bornée, sans commune mesure avec le coût d'une fuite de données. C'est aussi ce que je fais le plus souvent pour des clients arrivés avec un projet déjà commencé.

Étape 4 — Écrivez qui porte la responsabilité

Dans le devis ou le contrat : à qui appartient le code source, qui corrige un bug bloquant et sous quel délai, ce qui se passe si le prestataire devient indisponible, et où sont hébergées les données. Un prestataire sérieux répond à ces quatre points sans se crisper. C'est le test le plus rapide que je connaisse.

Quand l'IA seule suffit vraiment

Soyons honnêtes, parce que c'est utile : dans trois cas, faire appel à moi serait vous faire dépenser de l'argent pour rien.

• •Une page temporaire : vous testez une idée et il vous faut quelque chose en ligne demain.
• •Un site personnel sans enjeu : blog, portfolio, page de présentation sans objectif commercial.
• •Un prototype interne : montrer un concept à votre associé ou à un comité avant d'investir.

Dès que l'image de marque, la génération de contacts, le paiement ou les données clients entrent en jeu, le calcul s'inverse. Pour situer les ordres de grandeur, mon guide des prix à Lyon donne des fourchettes réelles.

Conclusion : l'IA a déplacé la valeur, elle ne l'a pas supprimée

L'étude METR ne dit pas que ces outils sont mauvais. Elle dit que leur bénéfice réel est plus faible et plus contextuel que le bénéfice ressenti — y compris par des professionnels compétents et de bonne foi.

Pour vous, dirigeant, la traduction est simple. Ce que vous achetiez hier, c'était principalement de la production. Ce que vous achetez aujourd'hui, c'est l'arbitrage (quoi construire, quoi refuser), la garantie (quelqu'un répond du résultat) et la durabilité (le produit tient dans deux ans et quelqu'un peut le reprendre). Ces trois postes ne sont pas automatisables, et ce sont eux qui décident si votre budget produit un actif ou une dette.

J'utilise l'IA tous les jours. Ce qui est livré, testé et garanti, c'est moi. C'est aussi pour ça que je livre le code source et que je documente ce que je fais : vous devez pouvoir partir avec, ou faire reprendre le projet par quelqu'un d'autre.

Vous pouvez voir concrètement ce que ça donne sur mes réalisations, et si vous cherchez à comparer plusieurs prestataires, mon guide pour choisir son agence web à Lyon liste les questions qui départagent vraiment.

Un projet en tête ? Parlons-en : 30 minutes pour identifier le vrai problème et vous dire honnêtement si vous avez besoin de moi, d'un outil, ou de rien du tout.

Questions fréquentes

L'IA peut-elle créer un site web complet toute seule ?

Elle peut produire quelque chose qui ressemble à un site complet, et parfois cela suffit — page temporaire, site personnel, prototype interne. Ce qu'elle ne produit pas, c'est une architecture pensée pour votre contexte, une stratégie de contenu, une conformité aux règles sur les données personnelles, et quelqu'un qui répond quand ça casse. L'écart entre « ça s'affiche » et « ça tient en production » reste entièrement à la charge d'un humain.

Vais-je payer moins cher maintenant que les développeurs utilisent l'IA ?

Moins que vous ne l'espérez. L'écriture de code représente environ un tiers du temps d'un projet d'application ; le reste est du cadrage, de la conception, des tests, de la mise en production et de la reprise après vos retours. L'étude METR de juillet 2025 a même mesuré une baisse de productivité de 19 % sur du code existant à contraintes. Ce qui a baissé, c'est le coût de produire du code qui a l'air de marcher — pas celui de garantir qu'il marche.

Est-ce grave si mon prestataire utilise l'IA sur mon projet ?

Non, et l'interdire n'aurait pas de sens : vous achetez un résultat, pas une méthode de saisie. Les bonnes questions sont ailleurs : qui relit le code livré, quels tests le couvrent, qui corrige un bug bloquant et sous quel délai, et à qui appartient le code source. Un prestataire qui répond précisément à ces quatre questions vous protège, qu'il utilise l'IA ou non.

Le code généré par IA pose-t-il un problème juridique ?

Son statut au regard du droit d'auteur reste débattu et dépend du degré d'intervention humaine. En revanche, votre responsabilité de donneur d'ordre envers vos utilisateurs et au titre du RGPD n'est pas discutée : elle vous incombe quelle que soit la manière dont le code a été produit. Le réflexe utile est contractuel — faites écrire que le code source vous est cédé et effectivement livré.

Comment vérifier qu'on ne me livre pas du code généré non relu ?

Trois demandes suffisent et ne coûtent rien : l'accès au dépôt de code avec l'historique des commits, la présence de tests automatisés sur les parcours critiques, et une démonstration en direct d'un cas limite de votre métier — pas du cas nominal. Un travail relu résiste à ces trois vérifications ; un copier-coller non relu s'effondre à la troisième.

L'IA va-t-elle rendre les développeurs inutiles à terme ?

Elle a déjà rendu inutile une partie du métier : le code répétitif que personne n'avait envie d'écrire. Ce qu'elle n'a pas entamé, c'est la traduction d'un problème d'entreprise flou en décisions techniques, l'arbitrage de ce qu'on refuse de construire, et l'engagement de responsabilité sur un livrable en production. Les mesures de 2025 vont dans ce sens : le travail se déplace de l'écriture vers la vérification et la décision, il ne disparaît pas.