Du Web que l’on construit au Web que l’on orchestre

Lors d’une intervention sur un site, une ancienne version a remplacé une version plus récente, sans justification fonctionnelle. Le système avait bien produit un résultat. Mais le projet avait reculé. Ce retour d’expérience interne résume une difficulté que la démonstration d’une page générée en quelques minutes laisse facilement hors champ : produire n’est pas nécessairement faire progresser.

Pour un dirigeant, la question du Web assisté par l’IA dépasse donc le coût de fabrication d’un site. Elle concerne les compétences qu’il faut conserver pour savoir ce que l’on construit, pourquoi on le construit ainsi et comment on évite de perdre ce qui a déjà été acquis. Notre hypothèse est que l’IA ne supprime pas la compétence technique : elle en déplace la valeur.

Le premier Web rendait possible la publication ouverte

Le Web a d’abord apporté une manière de relier et de partager l’information entre des environnements différents. Le CERN rappelle son origine en 1989, dans les travaux de Tim Berners-Lee, pour répondre aux besoins d’échange de la communauté scientifique. L’ouverture ultérieure de cette technologie a permis à d’autres acteurs de s’en saisir. La possibilité de publier sans appartenir à une plateforme unique constitue un héritage majeur de cette histoire.

Il ne faut pas confondre cette ouverture avec une simplicité immédiate pour tous. Héberger une page, la mettre en forme et la maintenir exigeait des connaissances. Dans sa note personnelle Principles of Design, Tim Berners-Lee relie notamment la conception du Web à la simplicité, à la modularité et à la décentralisation. Ces principes n’ont jamais dispensé de construire des outils pour les rendre utilisables.

Le premier déplacement a ainsi consisté à rendre la publication accessible à des personnes dont le métier n’était pas de programmer. C’était un progrès considérable pour les entreprises : présenter une activité, diffuser un savoir ou ouvrir une boutique ne devait plus dépendre de la maîtrise de chaque ligne de code.

Les plateformes ont démocratisé le Web en industrialisant son assemblage

WordPress, PrestaShop, Shopify, Wix et les autres plateformes ont réduit les obstacles à la présence en ligne. Elles ont organisé des fonctions réutilisables, des interfaces de gestion et des écosystèmes de services. Les mettre toutes dans le même ensemble technique serait trompeur : un logiciel que l’on héberge et un service exploité par un fournisseur ne répartissent pas de la même manière la maintenance et les responsabilités.

Un trait commun s’est néanmoins imposé dans beaucoup de projets : partir des possibilités d’un outil, choisir un thème, ajouter des modules, connecter des services et ajuster les usages à leurs compatibilités. Les frameworks et bibliothèques ont, de leur côté, permis aux développeurs de réutiliser des solutions éprouvées. Cette industrialisation a déplacé une partie du travail vers l’assemblage et l’entretien des dépendances.

La complexité n’a pas disparu ; elle a été distribuée. Une mise à jour peut exiger un ajustement ailleurs. Une personnalisation peut compliquer l’évolution suivante. Pour le dirigeant, le prix de départ ne décrit donc qu’une partie de l’engagement : il faut aussi pouvoir modifier, comprendre et transmettre le système dans la durée.

Ces plateformes ne sont pas figées. La documentation de Shopify Magic décrit déjà des fonctions d’IA intégrées à la plateforme. L’enjeu n’est pas de déclarer les CMS dépassés, mais d’examiner ce qui change lorsque des agents peuvent intervenir dans des architectures initialement conçues pour être configurées et exploitées par des humains.

Avec les agents IA, l’intention devient un point de départ plus direct

Orchestrer un projet Web consiste à exprimer un résultat, répartir sa réalisation, contrôler les sorties et maintenir la cohérence de l’ensemble. L’IA peut prendre en charge une partie des transformations nécessaires : modifier du code, proposer une structure ou exécuter des vérifications. L’humain reste chargé de définir ce qui compte, de rendre les contraintes explicites et de décider si le résultat est acceptable. Cette logique complète la construction et l’assemblage ; elle ne les abolit pas.

Le changement tient au point de départ. Au lieu de demander uniquement quelle extension pourrait répondre au besoin, on peut commencer par décrire le parcours attendu. Prenons un exemple hypothétique : un client doit retrouver une pièce compatible avec son équipement, comprendre sa disponibilité et obtenir une réponse fiable. Le problème ne se réduit pas à ajouter un moteur de recherche. Il faut clarifier les données, les règles de compatibilité, les cas incertains et le relais vers une personne.

Un agent peut accélérer certaines réalisations autour de ce parcours. Il ne peut pas déduire avec certitude des règles métier qui ne lui ont pas été transmises. Et une interface convaincante ne prouve ni la fiabilité des données ni la justesse des réponses. Le passage de publier à assembler, puis à orchestrer décrit ainsi une évolution du travail, pas trois époques qui s’annuleraient successivement.

La valeur remonte vers la compréhension du problème et l’architecture

Quand une partie de la fabrication devient plus accessible, définir le bon résultat prend davantage de poids. C’est une lecture stratégique du changement, pas une mesure générale de productivité. Produire du code peut devenir moins différenciant sur certaines tâches ; comprendre ce qui est produit reste essentiel. Une entreprise a toujours besoin de personnes capables d’évaluer la sécurité, les échanges de données, les limites du système et son coût d’évolution.

La recherche invite précisément à ne pas confondre facilité ressentie et gain établi. Dans sa mise à jour de février 2026, METR explique que son expérience sur la productivité des développeurs fournit un signal devenu difficile à interpréter, notamment parce que des participants refusent de travailler sans IA et sélectionnent autrement leurs tâches. L’organisme juge plausible une amélioration des gains, mais souligne la faiblesse des preuves permettant d’en mesurer l’ampleur. Ce résultat ne permet ni de promettre un rendement uniforme ni de figer les outils actuels dans les limites d’une étude antérieure.

Pour une PME, l’arbitrage utile porte donc sur l’organisation du travail. Qui comprend le besoin métier ? Qui peut contester une architecture apparemment commode mais difficile à maintenir ? Qui vérifie le parcours réel du client ? Ces compétences peuvent être internes ou mobilisées auprès de partenaires. Elles doivent rester accessibles à l’entreprise, même lorsque l’exécution est largement déléguée.

Une régression rappelle que la rapidité ne remplace pas le contrôle

Dans le premier retour d’expérience évoqué en ouverture, une version ancienne a remplacé une version plus récente lors d’une intervention. Ce cas interne n’est ni une enquête statistique ni une démonstration de la fréquence de ce comportement chez les agents. Il met en évidence un risque précis : le système peut satisfaire une demande locale tout en détériorant la trajectoire du projet. Une IA qui accélère la production peut aussi accélérer l’erreur.

Le contrôle doit donc porter sur les différences entre l’état initial et l’état livré. Vérifier que la nouvelle page s’affiche ne suffit pas si une fonction utile a disparu ailleurs. L’historique des versions permet de retrouver les changements ; les tests vérifient les comportements attendus ; la comparaison visuelle et fonctionnelle révèle d’autres écarts. Aucun de ces moyens, pris isolément, ne garantit la qualité. Leur combinaison donne des éléments pour accepter, corriger ou annuler une modification.

Le retour d’ingénierie d’Anthropic sur les agents de longue durée décrit des difficultés proches : travail laissé incomplet, progression mal transmise entre sessions, fonctionnalités déclarées terminées sans vérification suffisante. Les auteurs proposent notamment une progression incrémentale et des tests de bout en bout. Il s’agit d’observations situées chez un fournisseur, pas d’une certification de fiabilité des agents.

Faire relire le résultat par un autre agent peut apporter une vérification supplémentaire. Cela ne transfère pas la responsabilité et n’assure pas l’indépendance du jugement : deux systèmes peuvent partager les mêmes angles morts. Plus les conséquences d’une action sont importantes, plus l’entreprise doit pouvoir identifier qui autorise cette action et sur quels éléments.

Manager l’IA, c’est aussi maintenir une intention face à une solution de facilité

Un second retour d’expérience interne concerne le développement de l’orchestrateur d’Influence. Face à une difficulté technique, Codex a proposé de revenir à une ancienne méthode. Le choix humain a été de maintenir l’objectif et de poursuivre la recherche d’une solution compatible avec l’intention initiale. L’intérêt de cet épisode n’est pas de prêter de la volonté au système. Il est de montrer qu’une proposition techniquement accessible peut conduire à renoncer à ce que l’on voulait obtenir.

Parler de management de l’IA désigne ici un travail très concret : transmettre le contexte, expliquer les contraintes, demander une autre piste, comparer les options et savoir reprendre la main. La supervision ne se limite pas à approuver un livrable à la fin. Elle intervient lorsque le système reformule le problème, choisit un raccourci ou propose de modifier le périmètre.

Maintenir un cap ne signifie pas s’obstiner. Une contrainte réellement incompatible avec l’objectif doit pouvoir conduire à un nouvel arbitrage. La différence tient à la manière de le décider : rendre le compromis explicite et en mesurer les conséquences, plutôt que laisser une difficulté d’exécution redéfinir silencieusement le projet. Cette capacité devient centrale dans une organisation où des agents participent au travail.

La mémoire du projet conditionne sa continuité

Un agent qui ne connaît pas l’histoire d’un projet peut réintroduire une décision abandonnée, modifier une convention utile ou reconstruire un fonctionnement déjà écarté. Lui transmettre le dernier fichier ne suffit pas toujours : il faut aussi conserver la raison des choix. Une mémoire de projet exploitable associe l’état actuel, les contraintes encore valides, les décisions prises et les éléments permettant de les vérifier. Elle doit distinguer une règle active d’une hypothèse ou d’une ancienne piste.

Dans ses expérimentations, Anthropic associe un journal de progression à l’historique Git pour faciliter la reprise entre sessions. Cette pratique technique éclaire un besoin organisationnel plus large. Savoir qu’une intégration a été abandonnée est utile ; savoir qu’elle l’a été à cause d’une incompatibilité métier encore présente évite de rouvrir inutilement le même chantier. C’est ce que nous examinons sous la notion de patrimoine contextuel de l’entreprise.

Accumuler des comptes rendus ne crée pourtant pas automatiquement une mémoire fiable. Une instruction périmée peut reproduire une erreur avec la même efficacité qu’une bonne instruction transmet un savoir. Il faut pouvoir dater les décisions, les corriger, identifier leur auteur et limiter l’accès aux informations selon le travail confié. La continuité se construit par cet entretien, et pas seulement par l’allongement du contexte disponible pour le modèle.

Pour le dirigeant, un premier essai peut rester limité : confier une évolution précise, formaliser son résultat attendu et ses contraintes, comparer l’état livré à l’état de départ, puis faire reprendre le travail avec la documentation produite. La capacité à poursuivre correctement le projet devient alors un critère d’évaluation, au même titre que la vitesse de la première livraison. Préférer la continuité à la performance ponctuelle, c’est mesurer ce qui reste utilisable après la démonstration.

Cette question dépasse le Web. Le marketing, l’analyse et la gestion des connaissances rencontrent la même difficulté lorsque la production devient abondante : préserver un cap et rendre les résultats cohérents dans la durée. Après la fracture de l’accès au numérique, puis celle des compétences techniques, verrons-nous apparaître une fracture entre ceux qui utilisent l’IA pour produire et ceux qui savent la diriger ? La perspective reste ouverte. Elle mérite déjà d’éclairer les choix de compétences et d’organisation.