# Applications vivantes et contrats de résultat

*Première note : août 2026 · Dernière révision : octobre 2026*

Jusqu'ici, une grande partie du monde numérique s'est organisée autour de l'idée d'une application relativement figée : spécifiée, construite, livrée, maintenue, corrigée, et de temps à autre repensée. Même quand elle évolue en continu, son centre de gravité reste souvent une base de code gérée par des humains, au fil d'interventions périodiques.

Une nouvelle classe de logiciels pourrait se comporter moins comme un artefact fini que comme un organisme guidé. Le point de départ n'est plus seulement une spécification de produit figée. Ce peut être un contrat de résultat rédigé par des humains : ce que le système doit accomplir, quelles contraintes il doit respecter, quel seuil de qualité il doit tenir, et dans quelles limites il est autorisé à agir.

Cela n'abolit pas le génie logiciel, mais cela déplace son centre de gravité.

### Le contrat de résultat comme origine opérationnelle

Le contrat de résultat formalise l'intention au niveau qui compte vraiment : résultats, contraintes, autorité et évaluation. Au lieu de prescrire à la main chaque petit chemin d'implémentation, l'humain définit ce que l'application doit continuer à satisfaire.

Un système agentique peut alors échafauder, itérer, tester, comparer, réviser et publier en direction de ce résultat, à condition de disposer des autorisations, de l'observabilité et des canaux de retour nécessaires. Dans ce modèle, l'application n'est pas simplement construite puis entretenue de temps en temps. Elle est poussée en continu vers la conformité à son contrat.

C'est l'un des endroits où le futur agentique échappe le plus clairement à l'idée de l'IA comme simple assistant conversationnel. Ici, les agents deviennent des mainteneurs opérationnels, des constructeurs, des correcteurs et des médiateurs évolutifs à l'intérieur du logiciel lui-même.

### Un cas concret : la facture qui doit rester valide

Prenons un petit outil de facturation utilisé par des freelances français. Son contrat tient en une phrase : chaque facture qu'il produit doit être acceptée par les plateformes agréées par l'État, par lesquelles les factures françaises doivent désormais transiter. Depuis le 1er septembre 2026, toute entreprise en France doit pouvoir recevoir des factures électroniques, et à partir du 1er septembre 2027, les petites entreprises et les micro-entrepreneurs devront aussi en émettre, dans des formats structurés ou mixtes comme Factur-X. Les personnes qui utilisent l'outil sont précisément celles qui découvriront l'obligation sur le tard.

Les règles ne resteront pas figées. L'administration publie des précisions, les spécifications de format changent de version, les plateformes durcissent leur validation, et la période de tolérance annoncée au lancement finira par prendre fin. Dans le modèle classique, quelqu'un dans l'équipe finit par remarquer que quelque chose a changé, ouvre un ticket, et le correctif part avec la version suivante. Entre le changement et la livraison, des factures sont rejetées, et la clientèle est la première à s'en apercevoir.

Dans le modèle du contrat, la couche agentique surveille les sources qui définissent la validité : les textes officiels, les spécifications de format, les messages de rejet renvoyés par les plateformes. Une facture rejetée pour un motif que le système n'a jamais vu est une dérive, un écart entre le contrat et la réalité. L'agent la fait remonter jusqu'au champ ou à la règle en cause, vérifie quels flux de factures sont touchés, écrit la correction, la passe au validateur officiel et à chaque modèle de facture sur lequel s'appuie la clientèle, puis soumet le changement à relecture. Un humain l'approuve, parce que le contrat prévoit que toute modification touchant aux règles fiscales exige une signature humaine. La facture suivante passe.

Rien d'exotique dans cette boucle. Ce qui est nouveau, c'est son point de départ : non plus un ticket rédigé par quelqu'un, mais la distance entre ce que le système était censé garantir et ce qu'il a réellement fait.

> **Où en est-on (automne 2026)**
>
> Chaque pièce de cette boucle existe. Aucune n'est encore refermée autour d'un contrat.
>
> Côté construction, depuis mars 2026, un ticket Jira peut être confié à l'agent de code de GitHub Copilot (en préversion publique) : il lit le ticket et ses commentaires, pose des questions de clarification dans Jira quand il en a besoin, et rend une pull request en brouillon qui passe par les règles de relecture habituelles de l'équipe. Côté exploitation, Bits AI SRE de Datadog enquête seul sur les incidents, formule des hypothèses de cause racine et les confronte aux métriques, aux logs et aux traces. Une remédiation automatique, comme un rollback ou la modification d'un feature flag, est possible dans des garde-fous définis par le client, même si Datadog recommande lui-même que, dans la finance, l'agent propose et l'humain décide.
>
> Ce qui manque, c'est l'étape d'avant le ticket. Dans les deux cas, c'est encore un humain qui décide qu'il y a quelque chose à faire. L'agent exécute le travail ; il ne le déduit pas encore d'un objectif permanent.
>
> *Sources : GitHub changelog, « GitHub Copilot coding agent for Jira is now in public preview », 5 mars 2026 ; Datadog, annonces de DASH 2026 (Bits AI SRE).*

### Anatomie d'une application vivante

De quoi l'agent a-t-il vraiment besoin pour cela ? De moins qu'il n'y paraît. Donnez-lui cinq choses : l'application web elle-même, une adresse e-mail, un serveur Elastic, un accès au dépôt GitHub, et le droit de réentraîner le modèle au cœur de l'application. Cela suffit pour que l'application évolue d'elle-même, sous supervision, à travers trois boucles.

La première boucle est technique, et elle passe par Elastic. Chaque requête, chaque erreur, chaque pic de latence et chaque facture rejetée finit dans les logs. L'agent les lit en continu, comme le ferait une personne d'astreinte qui ne dormirait jamais. Il remarque que les rejets d'une plateforme ont bondi après une mise à jour de format, qu'une page s'est ralentie depuis le dernier déploiement, qu'une erreur n'apparaît que sur un navigateur particulier. Chaque anomalie devient une hypothèse, et chaque hypothèse confirmée devient un ticket dans le dépôt.

La deuxième boucle passe par les personnes qui utilisent l'outil, via les tickets GitHub et surtout par e-mail. Quelques-unes ouvrent des tickets. La plupart écrivent simplement à l'adresse du support, avec leurs propres mots, souvent agacées, rarement précises. L'agent répond, pose la question qui manquait, et transforme l'e-mail en ticket structuré : ce que la personne a essayé, ce qui s'est passé, quelle facture. Les demandes qui relèvent au fond de la même plainte sont fusionnées, si bien qu'une fonctionnalité réclamée par quarante freelances en quarante formulations différentes devient un seul ticket porté par quarante voix.

Les deux boucles aboutissent au même endroit : un ticket, puis une branche, un correctif, des tests, une pull request, et un déploiement quand le contrat le permet. Elastic montre ensuite si le correctif a vraiment fonctionné, ce qui referme la boucle.

La troisième boucle va plus loin. L'outil s'appuie sur un modèle pour lire ce que fait réellement un ou une freelance et décider quel régime de TVA s'applique et quelles mentions la facture doit porter. Chaque fois que quelqu'un corrige l'un de ces choix, par e-mail ou directement dans l'interface, la correction devient une donnée d'entraînement. Une fois qu'il s'en est accumulé assez, l'agent réentraîne le modèle, évalue la nouvelle version sur un jeu de factures vérifiées mis de côté, et ne la propose pour la production que si elle fait mieux sans casser ce qui marchait déjà. L'application change alors non seulement son code, mais sa manière de comprendre son propre domaine. À ce stade, le modèle n'est plus une commodité branchée de l'extérieur ; il fait désormais partie de la logique métier elle-même. Et c'est la seule partie qu'un concurrent ne peut pas copier en lisant le code : comme pour les présences dans la première partie, une compétence se télécharge, des poids non.

![Les trois boucles d'une application vivante : le retour technique via Elastic, le retour des personnes qui utilisent l'outil via l'e-mail et les tickets GitHub, et l'évolution du modèle par réentraînement, qui convergent toutes vers un agent lié par le contrat de résultat, avec une approbation humaine avant tout retour en production.](https://theagenticshift.org/img/living-application-loops.svg)

Là encore, c'est le contrat qui fixe les limites : quels changements peuvent partir seuls, lesquels exigent une signature humaine, et quelle version du modèle a le droit d'atteindre la production.

C'est pourquoi l'ancien vocabulaire de l'« application auto-réparatrice » est trop étroit. L'enjeu n'est pas seulement que le logiciel se répare après une panne. C'est qu'il puisse être continuellement échafaudé, corrigé, réorienté et avancé vers un objectif défini par des humains.

### L'avenir du logiciel comme adaptation supervisée

Ce qui ressort de tout cela, c'est une autre image du logiciel : un processus adaptatif supervisé qui avance sous contrainte vers des résultats définis par des humains, un peu comme on « fait grandir » aujourd'hui les modèles d'IA.

Ce pourrait être l'une des conséquences les plus profondes de la transition agentique. L'application est continuellement maintenue, corrigée et développée par des processus agentiques sous gouvernance.

Reste à savoir qui rédige ce contrat : une entreprise, une équipe ou, comme le suggère le chapitre suivant, les détenteurs d'un jeton.