L’IA peut désormais créer des sites web. Mais quelqu’un doit toujours la diriger.

Il y a encore quelques années, demander à une intelligence artificielle de créer un site web complet était surtout une manière très efficace de produire du désordre.

Elle pouvait générer une page d’atterrissage correcte. Elle connaissait suffisamment le HTML et le CSS pour créer quelque chose de convaincant sur une capture d’écran. Elle pouvait expliquer du JavaScript, écrire des composants isolés et proposer des solutions à des messages d’erreur.

Mais dès que le travail impliquait un projet existant, des structures de plateforme actuelles, plusieurs fichiers, de véritables contraintes commerciales ou des décisions devant rester cohérentes à travers tout un site, les failles apparaissaient rapidement.

L’IA oubliait les instructions précédentes. Elle inventait des fonctions qui n’existaient pas. Elle utilisait avec assurance des structures obsolètes, y compris pour les plus grandes plateformes. Elle modifiait un composant tout en en cassant un autre. Elle résolvait le problème visible sans comprendre le système qui l’entourait.

Utile, mais maladroite.

Cela a changé à une vitesse remarquable.

Les agents de programmation modernes peuvent analyser des dépôts, modifier plusieurs fichiers, exécuter des commandes, lancer des tests, utiliser des outils externes et poursuivre des tâches qui auraient autrefois exigé une longue succession de prompts coordonnés manuellement. OpenAI décrit Codex comme un agent d’ingénierie logicielle capable de créer des fonctionnalités, corriger des bugs, répondre à des questions sur une base de code et proposer des modifications depuis un environnement de développement isolé.

C’est une avancée fondamentale.

Cela ne signifie pas que l’on peut lâcher l’IA sans supervision sur n’importe quel projet. Cela signifie que le facteur limitant est en train de changer. La question n’est plus seulement de savoir si l’IA peut écrire du code.

La question la plus importante est de savoir si quelqu’un a créé un environnement dans lequel elle peut produire un travail utile.

De la génération de fragments de code au travail à l’intérieur de systèmes

La première génération d’assistance au développement par IA fonctionnait principalement au niveau des suggestions.

Vous décriviez un bouton, une fonction ou une page. Le modèle générait du code. Vous le copiiez dans votre projet, découvriez ce qui n’allait pas, puis reveniez avec un nouveau prompt.

Elle se comportait comme un assistant extrêmement rapide, mais doté d’une mémoire peu fiable.

Des outils comme GitHub Copilot ont déjà montré que cette assistance pouvait accélérer le développement. Dans une étude contrôlée de GitHub, les développeurs utilisant Copilot ont terminé une tâche de programmation nettement plus rapidement que le groupe témoin. Mais cette génération d’outils assistait encore principalement une personne qui restait responsable de chaque étape de l’implémentation.

Les agents actuels fonctionnent différemment.

Ils peuvent recevoir un objectif plus large, inspecter le projet, trouver les fichiers pertinents, effectuer des modifications coordonnées et vérifier certaines parties de leur propre travail. Le projet SWE-bench a été créé pour mesurer si des modèles de langage pouvaient résoudre de véritables problèmes logiciels issus de dépôts GitHub existants. Les premiers systèmes ne réussissaient qu’une petite fraction de ces tâches. Les agents récents obtiennent de bien meilleurs résultats, même si ces benchmarks doivent toujours être interprétés avec prudence.

L’IA n’est pas devenue infaillible du jour au lendemain.

Elle a toutefois acquis une boucle de travail :

Comprendre la demande.
Examiner l’environnement.
Choisir une action.
Utiliser un outil.
Observer le résultat.
Corriger l’approche.
Continuer jusqu’à ce que la tâche soit terminée ou bloquée.

OpenAI appelle cela la boucle d’agent : le système qui coordonne le modèle, ses instructions, ses outils et les retours reçus pendant son travail.

C’est cette boucle qui transforme un chatbot en quelque chose de plus proche d’un agent réellement opérationnel.

La percée ne se résume pas à un meilleur code

Un modèle d’IA moderne produit généralement un meilleur code que ses prédécesseurs. Mais la génération de code à elle seule n’explique pas les progrès récents.

La véritable percée est que l’IA sait de mieux en mieux travailler avec du contexte.

Ce contexte peut inclure :

la structure d’un dépôt ;
les composants et modèles de conception existants ;
la documentation du projet ;
les modèles de données ;
les conventions de nommage ;
les standards de développement ;
les décisions précédentes ;
les captures d’écran et références visuelles ;
les résultats de tests ;
les règles métier ;
les instructions stockées dans le projet.

Cela change profondément la collaboration.

Au lieu de demander :

« Crée un site web pour mon entreprise. »

nous pouvons fournir à un agent :

un dépôt existant ;
une stack technique définie ;
une bibliothèque de composants ;
un système visuel ;
des modèles de contenu ;
des critères d’acceptation ;
des règles précisant ce qu’il peut ou ne peut pas modifier ;
des commandes permettant de tester son travail.

Le résultat n’est toujours pas garanti. Mais l’agent travaille désormais à l’intérieur d’un système au lieu d’improviser l’ensemble du projet à partir d’une phrase vague.

Anthropic décrit un principe similaire dans ses recommandations pour Claude Code : de bons résultats dépendent de la capacité de l’agent à explorer la base de code, à vérifier son travail et à comprendre l’environnement dans lequel il opère. Ses travaux sur le context engineering insistent également sur le fait qu’un agent doit pouvoir récupérer l’information pertinente au moment où elle devient utile, plutôt que d’essayer de stocker toute la connaissance d’une organisation dans un prompt gigantesque.

C’est pourquoi l’expression « prompt engineering » devient trop limitée.

Le véritable travail se déplace vers le context engineering et la conception de systèmes.

L’IA est assez rapide pour construire la mauvaise chose à une vitesse impressionnante

L’idée fausse la plus dangereuse est que davantage d’autonomie réduit le besoin de direction humaine.

C’est exactement l’inverse.

Imaginez une équipe de construction extraordinairement rapide. Elle peut travailler jour et nuit, commander des matériaux, utiliser des machines et exécuter plusieurs tâches en parallèle.

Mais il n’y a ni architecte, ni plan approuvé, ni processus d’inspection.

La vitesse de l’équipe ne protège pas le projet. Elle amplifie chaque décision floue.

L’IA fonctionne de la même manière.

Elle peut mettre en œuvre très rapidement une mauvaise architecture. Elle peut créer des dizaines de composants incohérents au lieu d’un seul système réutilisable. Elle peut optimiser une fonctionnalité qui n’aurait jamais dû exister. Elle peut appliquer parfaitement une mauvaise règle métier à l’ensemble du projet.

Et comme le résultat semble souvent professionnel, l’erreur n’est pas toujours immédiatement visible.

Une interface soignée n’est pas la preuve d’un bon produit.

Un code fonctionnel n’est pas la preuve d’un système facile à maintenir.

La réussite d’un test ne prouve pas que le besoin commercial a été correctement compris.

C’est là que la responsabilité humaine reste essentielle.

Quelqu’un doit encore décider :

ce que le site doit accomplir ;
à qui il s’adresse ;
comment le contenu doit être structuré ;
quelles technologies sont appropriées ;
ce qui doit rester simple ;
quels risques sont acceptables ;
ce qui doit être vérifié manuellement ;
à quel moment l’IA résout le mauvais problème.

L’IA peut de mieux en mieux exécuter un plan.

Elle ne devrait toujours pas être chargée d’inventer seule l’ensemble du plan sans remise en question.

Comment nous utilisons l’IA chez Vayluna

Chez Vayluna, nous n’utilisons pas l’IA comme un bouton magique censé produire automatiquement des entreprises complètes.

Nous l’utilisons comme une couche opérationnelle à travers plusieurs projets.

Cela peut inclure :

analyser et reconstruire un site existant ;
créer des structures de pages réutilisables ;
organiser des collections de contenu ;
traduire et adapter du contenu à différents marchés ;
analyser des données produit ;
générer des premières versions de supports visuels et éditoriaux ;
vérifier la cohérence technique ;
documenter des workflows ;
étudier des marchés et des concurrents ;
créer des outils internes ;
préparer du contenu pour des articles et des vidéos.

Notre travail sur InstantTraveling en est un exemple. L’IA peut contribuer à la recherche, à l’architecture de l’information, aux systèmes de contenu, à l’implémentation technique et aux workflows de production répétables. Mais elle ne peut pas décider seule de ce qui rend un guide de voyage réellement utile, des conventions des grands sites de voyage que nous souhaitons rejeter ou de la voix éditoriale que le projet doit adopter.

Ce sont des décisions humaines.

Il en va de même lors de la reconstruction d’un projet ecommerce tel que VaySafe. L’IA peut analyser un catalogue, repérer des données incohérentes, créer des templates et mettre en œuvre une structure définie. Un opérateur doit encore déterminer quels produits ont leur place, ce que les clients doivent comprendre et quelles priorités commerciales sont réellement importantes.

La valeur ne réside pas dans la demande « crée un site ».

Elle réside dans une répartition intelligente du travail.

Responsabilité humaine

définir l’objectif ;
choisir l’architecture ;
établir les priorités et les limites ;
apporter le contexte commercial ;
reconnaître les compromis ;
approuver les décisions importantes ;
effectuer le contrôle qualité final.

Responsabilité de l’IA

inspecter ;
implémenter ;
comparer ;
transformer ;
tester ;
documenter ;
répéter ;
faire ressortir les incohérences.

Plus cette répartition est claire, plus l’agent devient utile.

Nous avons cessé de compter sur un prompt gigantesque

Une approche fréquente consiste à écrire un prompt de plus en plus long contenant tout ce que le modèle devrait savoir.

Cela fonctionne jusqu’au moment où cela ne fonctionne plus.

Les instructions se contredisent. Les détails importants se retrouvent noyés. Un ancien contexte reste présent alors qu’il n’est plus valable. Le modèle accorde son attention à la mauvaise partie du prompt. L’utilisateur suppose que l’IA se souvient d’une décision qui n’a jamais été enregistrée de manière fiable.

Un meilleur workflow place les connaissances importantes directement dans le projet.

Cela peut inclure :

un README clair ;
une documentation d’architecture ;
des design tokens ;
des composants réutilisables ;
des exemples de résultats validés ;
des instructions propres au projet ;
des tests automatisés ;
des schémas de contenu structurés ;
des checklists de livraison.

La description d’OpenAI de l’agent-first engineering défend la même idée générale : les équipes doivent de plus en plus concevoir des environnements, expliciter leur intention et créer des boucles de feedback permettant aux agents d’effectuer un travail fiable.

Autrement dit, la qualité du résultat ne dépend pas uniquement de l’intelligence du modèle.

Elle dépend aussi du système qui l’entoure.

L’autonomie commence après l’architecture

L’expression « IA autonome » peut donner l’impression que l’humain disparaît.

Dans un travail réellement utile, l’autonomie commence généralement seulement après que quelqu’un a réduit l’ambiguïté.

Un agent peut travailler longtemps sans intervention constante lorsqu’il sait :

à quoi ressemble un résultat réussi ;
où se trouvent les fichiers pertinents ;
quelles commandes il peut utiliser ;
quelles règles ne sont pas négociables ;
comment vérifier le résultat ;
quand il doit s’arrêter et demander une décision.

Ce n’est pas une autonomie sans limites.

C’est une autonomie déléguée dans un cadre contrôlé.

Cela ressemble à la gestion d’un collaborateur compétent. Contrôler chaque frappe au clavier gaspille ses capacités. Ne lui donner ni objectif ni limite crée des risques inutiles. Le but n’est ni le contrôle total ni la liberté totale.

Le but est de définir clairement un domaine de responsabilité.

Là où l’IA échoue encore

Les progrès sont réels, mais les limites le sont aussi.

Les agents de programmation peuvent encore :

s’appuyer sur une documentation obsolète ;
mal comprendre la structure actuelle d’une plateforme ;
inventer des API, des paramètres ou des dépendances ;
négliger des cas limites ;
introduire des problèmes de sécurité ;
modifier des fichiers en dehors du périmètre prévu ;
corriger un symptôme au lieu du problème sous-jacent ;
annoncer qu’une tâche est terminée alors qu’un travail important manque encore ;
produire des affirmations plausibles mais non vérifiées ;
conserver une mauvaise hypothèse architecturale parce qu’elle figurait dans la demande initiale.

Les benchmarks ne suppriment pas cette incertitude. Certaines recherches soulignent également que les benchmarks formels peuvent surestimer les performances par rapport au développement interactif quotidien, où les demandes sont moins précises et les environnements plus désordonnés que dans un test soigneusement préparé.

Cela ne signifie pas que les agents sont inutiles.

Cela signifie que la vérification fait toujours partie du travail.

La bonne réponse à la faillibilité de l’IA n’est pas de rejeter l’outil. C’est d’intégrer la relecture, les tests et les preuves dans le workflow.

Cela supprime-t-il le besoin de développeurs ?

Non.

Mais cela modifie la nature du travail de développement à forte valeur.

Moins de temps pourra être consacré à écrire manuellement du code répétitif. Davantage de temps pourra être investi dans :

l’architecture ;
le jugement produit ;
la pensée systémique ;
la sécurité ;
l’expérience utilisateur ;
la vérification ;
l’intégration ;
la compréhension de l’entreprise derrière le logiciel.

Pour les petites entreprises, l’effet peut être encore plus important.

Un fondateur ou un opérateur possédant peu de compétences techniques peut désormais participer beaucoup plus directement à la construction d’un logiciel. Il peut expliquer le problème métier, évaluer les résultats visibles et guider les priorités, tandis qu’un agent exécute un travail qui aurait autrefois nécessité bien davantage d’implémentation manuelle.

Cela ne transforme pas instantanément chaque fondateur en développeur senior.

Mais cela réduit la distance entre une idée et une première version fonctionnelle.

Les personnes qui en profiteront le plus ne seront pas nécessairement celles qui connaissent le prompt le plus malin. Ce seront celles qui comprennent suffisamment bien leur problème pour construire un système utile autour de l’IA.

Un site web n’est pas le résultat d’un seul prompt

Un site web moderne peut aujourd’hui être construit avec une quantité impressionnante d’assistance par IA.

L’IA peut contribuer au code, au contenu, aux visuels, aux traductions, aux tests et à la documentation. Elle peut exécuter de manière autonome des tâches bien définies à travers un dépôt. Elle peut même détecter et corriger certaines de ses propres erreurs.

Mais un bon site reste le résultat de choix.

Que faut-il dire ?

Que faut-il laisser de côté ?

De quoi le visiteur a-t-il besoin en premier ?

Quelle interaction crée de la confiance ?

Quelle technologie convient au projet ?

Qu’est-ce qui peut échouer ?

Qu’est-ce qui ne devrait jamais être automatisé aveuglément ?

Ces questions ne peuvent pas être déléguées sans réflexion.

L’IA est passée du rôle d’assistant maladroit à celui de partenaire d’exécution capable. Ce progrès est réel, et il s’est produit plus vite que la plupart des gens ne l’avaient prévu.

Mais les meilleurs résultats ne viennent pas du fait de la laisser agir sans contrôle.

Ils viennent du fait de lui donner quelque chose qui mérite d’être suivi.

L’avenir du développement assisté par IA n’est pas un prompt vide suivi d’une entreprise terminée.

C’est un humain qui définit l’architecture, construit les boucles de feedback et fixe le niveau de qualité, puis laisse l’IA prendre en charge une part de l’exécution qui aurait autrefois été impossible.

C’est ainsi que nous l’utilisons chez Vayluna.

Pas comme un substitut à la direction.

Comme un multiplicateur une fois que cette direction existe.