Concevoir un site à la main quand tout pousse à déléguer à l'IA

Sur LinkedIn, un seul récit circule. On décrit la journée d’un concepteur web comme une suite d’instructions données à un agent. On génère une page, on corrige par un autre prompt, on régénère, on déploie. Le métier se résume à savoir formuler la bonne demande. Tout le reste serait du temps perdu.

Je travaille autrement. Pas par méfiance de principe, et pas par nostalgie. Par choix de l’endroit où je place l’outil.

Le faux débat

On oppose deux camps. D’un côté ceux qui confient le projet entier à un agent. De l’autre ceux qui refusent l’IA en bloc. Cette opposition arrange tout le monde parce qu’elle est simple. Elle ne décrit pas ma pratique.

J’utilise l’IA tous les jours. Pour explorer une piste, débroussailler une documentation, relire un fragment, accélérer une recherche. La question n’est pas d’en user ou de s’en passer. La question est de savoir ce qu’on lui donne et ce qu’on garde.

Garder, ici, veut dire l’architecture du projet, les décisions qui structurent, le code qui engage la conformité et la responsabilité. Donner veut dire les tâches où l’outil fait gagner du temps sans rien décider à ma place. La frontière n’est pas idéologique. Elle est technique, et elle a des conséquences.

Ce que je garde d’abord, ce n’est pas le code

Avant la première ligne de code, il y a un travail qu’on voit rarement et qui décide pourtant de tout. Un client n’arrive jamais avec un besoin propre. Il arrive avec une envie de site, des références vues ailleurs, quelques idées déjà arrêtées. Mon premier travail n’est pas de produire. C’est de démêler. Qu’est-ce que ce site doit faire, pour qui, et qu’est-ce qui n’a pas à exister.

La moitié de ce travail consiste à écarter. Une page d’accueil spectaculaire qui plombe l’accessibilité. Un menu à rallonge que personne ne lira. Une fonctionnalité qui flatte l’œil et ajoute une dépendance sans servir personne. Mon rôle est autant de retrancher que de proposer. Le client ne me paie pas pour empiler, mais pour garder l’essentiel et savoir pourquoi.

C’est là que la comparaison avec l’agent s’arrête net. Un outil génératif produit ce qu’on lui demande. Il ne conteste pas la demande. Vous lui décrivez le site surchargé que vous croyez vouloir, il vous le fabrique, sans broncher. Extraire un besoin que le client formule mal, et trancher entre ce qui doit exister et ce qui doit disparaître, suppose d’être en face de quelqu’un, de lire ce qui n’est pas dit, et d’assumer une décision. Ces deux gestes ne se délèguent pas, parce qu’ils n’imitent rien. Ils décident.

Le code vient après, et il est la trace écrite de ces décisions. Tout ce qui suit dans cet article découle de là.

La sobriété ne s’arrête pas à la page livrée

L’écoconception se mesure souvent au poids de la page finale. Le nombre de requêtes, le volume des images, la sobriété du code envoyé au navigateur. C’est juste, mais c’est incomplet.

La manière dont on produit ce code compte aussi. Multiplier les allers-retours avec un agent, générer puis corriger puis régénérer, consomme à chaque appel. Une fonctionnalité construite par dix prompts successifs a un coût que la page finale ne montre pas. Une conception réfléchie en amont produit moins de déchet en cours de route.

Cette cohérence me paraît évidente une fois posée. Si je défends la sobriété dans le résultat, je ne peux pas la perdre dans le processus. Concevoir à la main une partie du projet, c’est aussi refuser de transformer chaque étape en série de requêtes.

Signer ce que je livre

Je travaille avec des établissements scolaires, des thérapeutes, des TPE ou encore des indépendants. Quand je livre un site, je signe ce que je livre. Cette phrase semble banale. Elle ne l’est plus quand on délègue la conception à un agent.

Confier un projet à un outil génératif, c’est introduire du code que je n’ai pas audité, des dépendances que je n’ai pas choisies, parfois des données client glissées dans un prompt sans qu’on y pense. Pour un site institutionnel, la chaîne de responsabilité n’est pas une abstraction. Quelqu’un répond du résultat. Difficile de répondre de ce qu’on n’a pas lu.

Garder la main sur les décisions structurantes, c’est pouvoir expliquer chaque choix à mon client. Pourquoi cette dépendance et pas une autre. Où vont les données. Ce que fait ce bout de code. Cette capacité à rendre compte fait partie du travail. Elle ne se délègue pas.

L’accessibilité résiste à la génération automatique

Le code produit par un agent passe rarement un audit RGAA sans reprise. Les patterns ARIA mal posés, les landmarks absents, les contrastes approximatifs, les rôles appliqués au hasard. L’outil produit du visuel qui semble fonctionner et qui échoue dès qu’on le teste avec un lecteur d’écran ou qu’on le confronte aux critères.

On objecte qu’il suffit de cadrer le prompt, d’ajouter des règles d’accessibilité, de poser le contexte RGAA. J’ai essayé. Le résultat reste insuffisant, et je crois que la raison tient à ce que ces modèles ont appris.

Un modèle est entraîné sur le web tel qu’il est. Or le web, dans son immense majorité, n’est pas accessible. Quand on demande un composant accessible, l’outil reproduit ce qu’il a vu le plus souvent, c’est-à-dire des formes qui ressemblent à de l’accessible sans en respecter les règles. Le cadrage corrige la surface. Il ne corrige pas ce qui a été intégré comme normal. On obtient une imitation plus soignée de l’erreur, pas une structure juste. C’est ce que je retrouve sur le terrain, audit après audit.

L’accessibilité ne se déduit pas de l’apparence. Elle se construit dans la structure, dans l’ordre du document, dans le sens porté par le balisage. Ce sont précisément les endroits où la génération automatique se trompe le plus, parce qu’elle imite des formes sans comprendre ce qu’elles servent.

Concevoir à la main les composants qui engagent l’accessibilité n’est pas un luxe. C’est la condition de la conformité. Reprendre après coup du code généré coûte souvent plus cher que de l’avoir écrit en sachant ce qu’on faisait.

Ce que « perdre du temps » veut dire

Dans le vocabulaire actuel, écrire un composant à la main plutôt que de le générer, c’est perdre du temps. Je conteste la mesure.

Le temps passé à concevoir en comprenant est du temps qui ne revient pas en correction. Le temps gagné par génération massive se paie souvent plus tard, en dette technique, en code que personne ne maîtrise. Ce qu’on appelle lenteur est parfois la seule manière d’aller au bout sans détour.

Et il ne s’agit pas que du code. Un site se conçoit en étapes, de l’analyse du besoin à la livraison, en passant par l’architecture de l’information, le contenu, le design, l’intégration, les tests. Chacune de ces étapes contient des tâches qu’on pourrait automatiser entièrement. Je m’appuie sur l’IA dans presque toutes, en soutien, pour aller plus vite sur ce qui n’engage rien. Mais je n’en délègue aucune à cent pour cent, le code compris. Garder la main sur une part de chaque étape, c’est garder le fil du projet d’un bout à l’autre, comprendre comment une décision prise à l’analyse se répercute à l’intégration. Ce fil se perd dès qu’on confie un maillon entier à un agent.

Il y a aussi quelque chose de plus simple. Je prends plaisir à ce travail. Comprendre un besoin, structurer une information, poser une architecture propre, etc. Ce plaisir n’est pas un argument commercial, mais il tient le reste. On travaille mieux ce qu’on aime faire.

Une pratique mixte et assumée

Rien de tout cela n’est un refus de l’outil. C’est un usage situé. L’IA pour ce qu’elle accélère sans décider. La main pour ce qui structure, engage et se signe.

Une précision importante. L’usage massif d’agents a sans doute toute sa place dans certains contextes. De très gros sites, des applications complexes, de grandes équipes qui doivent industrialiser leur production et coordonner des dizaines de contributeurs. Là, l’automatisation poussée répond à un vrai problème d’échelle. Je ne juge pas cette pratique, elle ne s’adresse simplement pas à mon métier.

Mon cadre, ce sont des sites de thérapeutes, de TPE, d’indépendants, d’établissements scolaires. Des projets à taille humaine, où la relation directe avec le client compte autant que la livraison. Déployer une chaîne agentique complète pour ce type de site me paraît démesuré. On répond par une artillerie d’industrialisation à un besoin qui demande de la justesse, pas de la masse. C’est de l’overengineering, et l’overengineering a un coût, en complexité, en dépendances, en sobriété perdue. La conception à la main n’est pas seulement un choix de qualité ici. Elle est aussi à l’échelle du projet.

Si vous cherchez quelqu’un qui livrera vite en générant tout, je ne suis pas la bonne personne. Si vous cherchez un site dont chaque choix peut s’expliquer, qui reste sobre dans sa conception comme dans son résultat, alors cette manière de travailler est exactement ce qui fait la différence.

Concevoir à la main, aujourd’hui, n’est pas un retour en arrière. C’est garder ce qui doit l’être : la décision de ce qui mérite d’exister, et la responsabilité de chaque choix qui en découle.


Travaillons ensemble

Si cette manière de concevoir correspond à ce que vous cherchez pour votre projet, découvrez mes services, ou contactez-moi directement. Sites accessibles, sobres et maîtrisés, pensés pour les thérapeutes, les TPE, les indépendants et les établissements scolaires.

← Retour au blog