Pendant longtemps, concevoir un site web consistait notamment à organiser l'information dans une interface : une navigation, des pages, des parcours et des interactions. Cette interface reste essentielle pour les visiteurs humains. Mais elle n'est déjà plus le seul point d'accès aux services et aux contenus d'une entreprise. Un assistant IA peut lire plusieurs sites, comparer des offres et restituer une synthèse sans que l'utilisateur ouvre les pages correspondantes.
Ce changement dépasse la question de la visibilité dans ChatGPT. Il touche à la façon dont nous structurons les informations, développons les fonctionnalités et choisissons les outils qui les administrent. Quatre distinctions nous semblent particulièrement utiles pour concevoir des projets numériques dans ce contexte.
1. Être lisible par un agent ne signifie pas être utilisable par un agent
Pour permettre à un système automatisé de comprendre une entreprise, les fondamentaux du web restent précieux : HTML accessible, textes explicites, liens cohérents, données structurées lorsque leur usage est pertinent. Les services, les références et les informations importantes ne devraient pas dépendre exclusivement d'une animation ou d'une interaction visuelle.
Mais imaginons un agent qui doit non seulement comparer trois prestataires, mais aussi préparer une demande de devis. Identifier une prestation sur une page et transmettre correctement un brief sont deux opérations très différentes. La seconde suppose de connaître les champs attendus, les règles de validation, les droits nécessaires et la manière de confirmer le résultat.
Une API documentée peut offrir un chemin robuste pour certaines actions, mais ce n'est pas l'unique solution : des agents peuvent également interagir avec des formulaires et des interfaces existantes. L'important est de distinguer la lecture d'informations publiques de l'exécution d'une action, particulièrement lorsqu'elle modifie des données ou engage un utilisateur.
La lisibilité des contenus est un point de départ. La capacité d'action demande une conception supplémentaire.
2. Quand un agent écrit le code, les critères de qualité ne disparaissent pas
Les agents de développement sont capables de produire des fonctionnalités entières. Leur résultat peut être convaincant au premier regard, fonctionner dans une démonstration et même réussir les tests prévus. Cela ne garantit pourtant ni une architecture durable ni une bonne compréhension des contraintes métier.
Prenons une intégration entre des paiements et des comptes utilisateurs. Associer les deux par adresse email peut sembler suffisant lors des premiers essais. Mais si l'adresse change, ou si les données ne correspondent plus, la relation devient fragile. Un identifiant stable et une règle de rapprochement explicite sont généralement préférables. Le problème n'est pas syntaxique : c'est une décision de conception.
L'agentic engineering consiste notamment à préparer ce terrain avant de déléguer : définir les invariants métier, les exigences de sécurité, les critères d'acceptation et les cas limites. Puis soumettre le résultat à des tests automatisés, à une revue de code et à une validation humaine proportionnée au risque. L'agent peut contribuer à toutes ces étapes ; il ne décide pas seul de ce qui est acceptable.
À mesure que la production accélère, la capacité à formuler de bonnes contraintes et à identifier les mauvaises décisions devient plus importante, pas moins.
3. Avant de construire une application IA, tester ce qu'un modèle sait déjà faire
Andrej Karpathy a raconté avoir créé MenuGen, une application capable d'illustrer les plats d'un menu photographié, avant de constater qu'un modèle généraliste pouvait obtenir un résultat similaire à partir de l'image et d'une instruction. L'anecdote n'annonce pas la disparition des applications. Elle invite à réexaminer leur valeur ajoutée.
Si un outil se limite à habiller un prompt avec une interface, il risque de devenir rapidement redondant. En revanche, un logiciel peut justifier pleinement son existence lorsqu'il apporte des intégrations métier, une gestion fine des accès, une expérience spécifique, des résultats reproductibles, de la traçabilité ou des mécanismes de validation.
Avant de développer, nous trouvons utile de réaliser un prototype avec les outils existants, puis de documenter ce qui manque réellement : quelles données faut-il connecter ? Quelles opérations doivent être fiables ? Qui doit approuver quoi ? Quel coût de maintenance l'organisation est-elle prête à assumer ?
La bonne question n'est pas seulement « peut-on le construire ? », mais « qu'apporte ce développement que les outils existants ne garantissent pas ? »
4. Un CMS accessible par API n'est pas automatiquement prêt pour les agents
Le sujet devient concret côté contenu. Une équipe marketing peut vouloir actualiser cent fiches produits dans trois langues. Un agent pourrait lire les données du CMS, préparer des corrections, proposer des traductions et signaler des incohérences. Mais lui donner un accès complet à la publication serait rarement une bonne première étape.
Une organisation plus sûre distingue les permissions de lecture et d'écriture, l'enregistrement en brouillon et la mise en ligne. Elle prévoit un historique des modifications, une validation humaine et, lorsque c'est nécessaire, des possibilités de revenir en arrière. Les capacités exactes dépendent du CMS, de son API et des intégrations mises en place.
Cela ajoute un critère au choix des plateformes. L'ergonomie pour l'équipe éditoriale reste importante, mais il faut aussi considérer la structure des contenus, la granularité des droits et les possibilités de composer des workflows contrôlés. Un CMS headless peut faciliter certaines intégrations ; il ne résout pas à lui seul les questions de gouvernance.
Ce que cela change dans notre manière de concevoir
Chez ultraperfekt, ces évolutions nous encouragent à poser quelques questions plus tôt dans les projets : qui doit pouvoir lire ces contenus, humain ou agent ? Quelles actions peuvent être automatisées ? Comment vérifier leur résultat ? Et faut-il vraiment développer un nouvel outil ?
Les principes de base restent les mêmes : comprendre le besoin, structurer l'information, choisir une architecture adaptée et tester ce qui est livré. L'IA ne rend pas ces étapes obsolètes. Elle augmente surtout le nombre de situations où elles doivent être pensées au-delà de l'interface graphique.
