Aller au contenu
Retour aux articles
Intelligence artificielleDéveloppement webAgents IARetour d’expérience

26. Développement agentique : ce qui change dans ma façon de développer

Par Antoine Quarroz Publié le 7 min de lecture
26. Développement agentique : ce qui change dans ma façon de développer

Du chat qui propose du code à l’agent qui agit dans un projet : mon regard sur le développement agentique, les essais, les coûts et les vérifications qui restent essentiels.

Voir mon accompagnement en développement web

Développer avec l’IA ne consiste plus seulement à demander un morceau de code puis à le copier dans un projet. Une autre manière de travailler prend de la place : donner un objectif à un agent qui peut consulter les fichiers, proposer des modifications, lancer des contrôles et reprendre son travail à partir des résultats.

C’est ce qu’on appelle le développement agentique. Le terme semble technique, mais la question qu’il pose est très concrète : que peut-on déléguer à une IA sans perdre la maîtrise du logiciel que l’on construit ? Dans mes projets, notamment Hermes, cette question touche autant le développement que l’interface, les validations et la mise en ligne.

Je ne présente pas ici un bilan chiffré d’une année de travail : je n’ai pas de mesure consolidée qui permettrait de le faire sérieusement. Je partage plutôt les choix que cette façon de développer m’amène à faire aujourd’hui, avec ses possibilités et ses limites.

Qu’est-ce qu’un agent change par rapport à un chat ?

Un chat peut expliquer une erreur ou proposer une fonction. Un agent dispose aussi d’outils pour agir dans un environnement autorisé. Il peut lire un fichier, rechercher une référence, modifier du code ou exécuter une commande. Il observe ensuite le résultat pour décider de la suite.

OpenAI décrit ce fonctionnement comme une boucle entre les instructions, le modèle et les outils. Le résultat d’un outil revient dans le contexte, puis le modèle peut demander une nouvelle action ou terminer sa réponse. Cette explication figure dans son article technique du 23 janvier 2026 sur la boucle de Codex.

Imaginez une demande simple : rendre un formulaire plus facile à utiliser sur téléphone. L’agent peut examiner les composants concernés, repérer les contraintes de mise en page, préparer une correction et lancer les contrôles disponibles. Mais une commande qui réussit ne démontre pas que le formulaire est agréable à utiliser. Il faut encore regarder le rendu et parcourir le formulaire.

L’agent peut avancer dans le travail. Il ne connaît pas automatiquement votre définition d’un bon résultat.

Le vrai changement : mieux définir ce que je veux obtenir

Pour moi, cette approche rend le cadrage encore plus important. « Améliore cette page » laisse beaucoup de place à l’interprétation. « Sur téléphone, le bouton doit rester accessible, le texte doit être lisible et le formulaire ne doit pas déborder » donne un résultat que l’on peut vérifier.

La différence se voit particulièrement dans le design. Une interface peut respecter les règles du code tout en ayant des espacements maladroits, des liens trop petits ou une animation désagréable. Mes itérations sur Hermes portent justement sur des questions comme la lisibilité des rapports, la compréhension des validations et la fluidité de la navigation.

L’IA n’enlève donc pas le besoin de faire des choix. Elle oblige à exprimer ces choix plus clairement, puis à vérifier qu’ils apparaissent réellement à l’écran. Le développement devient aussi un travail de description, d’observation et de correction.

Hermes : rendre les résultats compréhensibles avant de les utiliser

Hermes est mon cockpit pour consulter des missions, leurs rapports et les éléments qui demandent une décision. Le projet comprend une application Mac et un compagnon iPhone privé. Il m’amène à travailler sur une difficulté très concrète : recevoir un résultat ne suffit pas, il faut comprendre ce qu’il signifie et ce qu’on peut en faire.

Un rapport peut être récent sans démontrer que toute la mission a réussi. Un brouillon peut être pertinent sans être prêt à être envoyé. Une interface peut afficher un état rassurant alors que la collecte a besoin d’une reconnexion. Il faut donc distinguer le résultat reçu, son contrôle et l’action autorisée.

C’est aussi la logique du flux éditorial de mon site : préparer un article, vérifier ses sources et sa couverture, publier par une interface dédiée, puis contrôler la page publique. Les brouillons destinés aux réseaux sociaux gardent leur propre étape de validation. Une autorisation de publier un article ne vaut pas automatiquement autorisation d’envoyer un message ailleurs.

Ces exemples décrivent mon organisation actuelle. Ils ne constituent pas une promesse qu’un agent peut gérer sans supervision tous les processus d’une entreprise.

Expérimenter sans transformer chaque idée en usine à gaz

La possibilité de déléguer davantage peut donner envie de multiplier les agents et les étapes. Je préfère partir d’un problème précis : qu’est-ce qui bloque, quel résultat attend-on et comment saura-t-on que la solution fonctionne ?

Anthropic distingue les workflows dont le chemin est défini par le code et les agents qui choisissent dynamiquement leurs actions. Dans son guide publié le 19 décembre 2024, l’entreprise recommande de commencer par une solution simple et d’ajouter de la complexité lorsqu’elle apporte une valeur mesurable. Ce principe d’architecture reste utile ; ce texte n’est pas un catalogue des outils disponibles en octobre 2026.

Dans un projet web, une règle déterministe reste souvent adaptée à une tâche prévisible. L’agent devient intéressant lorsqu’il faut explorer des fichiers, interpréter un problème ou adapter une correction. Le choix dépend du travail à réaliser, pas du prestige du mot « agent ».

Pour un essai, je cherche un périmètre qui permet de revenir en arrière et un résultat assez petit pour être relu. Un écran, un parcours ou une correction précise permettent d’apprendre avant d’élargir le chantier.

Et les coûts ? Il faut compter le travail complet

Le prix d’un abonnement ou des appels au modèle est une partie du coût. Il faut aussi considérer le temps passé à préparer les instructions, relire les changements, corriger les erreurs et maintenir ce qui a été ajouté.

Un agent qui produit beaucoup de code peut déplacer le travail vers la vérification. Un prototype rapide peut ensuite demander une reprise pour gérer les droits d’accès, les erreurs ou les données réelles. À l’inverse, une petite correction bien cadrée peut être utile sans faire intervenir une architecture compliquée.

Je préfère donc examiner une fonctionnalité terminée plutôt que compter les lignes produites. Est-elle compréhensible ? Fonctionne-t-elle sur les appareils concernés ? Peut-on la maintenir ? Le résultat justifie-t-il les ressources engagées ?

Pour quantifier un gain, il faut enregistrer le temps complet et la qualité obtenue. J’explique cette méthode dans l’article sur la mesure du gain de temps d’une automatisation IA. Sans ces données, annoncer un pourcentage d’économie serait une impression présentée comme une preuve.

Mon rôle reste de décider et de vérifier

La partie que je souhaite déléguer davantage est l’exécution d’un travail bien défini. La responsabilité du produit reste entière : décider ce qui est utile, protéger les accès, comprendre les changements et vérifier les parcours importants.

Les contrôles automatiques apportent des preuves sur les points qu’ils couvrent. Ils ne remplacent pas une relecture du code ni un essai visuel. Une modification préparée n’est pas encore une modification déployée. Une page déployée doit encore être contrôlée dans son environnement public.

C’est cette continuité qui m’intéresse dans le développement agentique : aller d’une intention à un résultat concret en gardant des étapes lisibles. Le métier évolue, mais construire un outil fiable demande toujours du jugement, de la précision et de l’attention aux personnes qui vont l’utiliser.

Ce que cela signifie pour votre projet

Pour une PME, l’intérêt n’est pas de savoir combien d’agents travaillent en arrière-plan. Il est de disposer d’un site ou d’un outil qui répond au besoin, avec des responsabilités et des critères de réussite clairs.

Si vous préparez un projet de site internet en Valais, nous pouvons partir de votre usage réel avant de choisir les technologies et les étapes de réalisation. Présentez-moi votre projet : l’objectif est de construire quelque chose d’utile et de vérifiable, avec ou sans agent selon ce que le projet demande.

Sources techniques vérifiées le 5 octobre 2026 : OpenAI et Anthropic. Les exemples Hermes et du flux éditorial décrivent mes projets ; aucun gain de temps, coût ou résultat commercial non mesuré n’est annoncé.