Cloudflare propose désormais l’approche Agent Development Lifecycle

Les responsables techniques ont consacré les dernières décennies à élaborer des solutions permettant à une multitude de programmeurs de travailler ensemble sur une base de code partagée. Ces travaux remontent à la publication intitulée « Systems Development Lifecycle » (RAND, 1975), aujourd’hui communément appelée « cycle de vie du développement logiciel » (SDLC, Software Development Lifecycle), qui définit les phases suivantes :

• Planification
• Conception
• Mise en œuvre
• Test
• Déploiement
• Maintenance
• Abandon

Grâce à l’IA, l’étape qui était auparavant la plus longue et la plus coûteuse, à savoir la mise en œuvre, est désormais devenue la plus rapide et la moins chère. Cette évolution a, à son tour, eu des répercussions en aval : les personnes responsables de toutes les autres étapes du cycle de développement logiciel se sont retrouvées submergées de travail. Cela va du personnel assurant la maintenance de projets open source, qui est submergé par des milliers de requêtes d’extraction (pull requests) et de rapports d’incident, aux ingénieurs de production, qui tentent de prévenir les défaillances des systèmes de production tandis que le rythme des déploiements logiciels augmente de plusieurs ordres de grandeur.

Nous essayons tous de protéger nos systèmes, nos clients et nous-mêmes contre le désordre que peut engendrer l’IA.

Mais la réponse, paradoxalement, consiste à permettre aux agents d’en faire davantage. Ça n’est que justice, après tout ! Vous n’accepteriez jamais qu’un ingénieur de votre équipe écrive du code, puis compte sur quelqu’un d’autre pour le valider, le fusionner, le déployer, assurer la permanence en production et trier les bugs signalés. Cependant, c’est précisément ce qu’exigent actuellement la plupart des entreprises de leurs agents. Les modèles ont accompli des progrès considérables, et les agents s’exécutent désormais sur des horizons temporels plus longs, ce qui leur permet d’accomplir des tâches d’ampleur considérablement plus grande. Cependant, leur utilisation n’est pas encore uniforme à l’échelle du cycle de vie du développement logiciel.

Cloudflare traite les agents de la même manière que ses clients : ils peuvent acheter des domaines, créer des comptes temporaires et utiliser l’API Cloudflare dans son intégralité. Nous savons que les agents ont besoin d’API et d’outils pour pouvoir gérer l’ensemble du cycle de vie du développement logiciel pour le compte de nos clients, et pas uniquement lors de la phase initiale.

C’est pourquoi nous présentons aujourd’hui une nouvelle suite d’outils qui permettent aux agents d’aller au-delà de la simple génération de code et de s’impliquer davantage dans le cycle de vie du développement logiciel. Nous partageons ici ce que nous avons développé et appris en essayant de résoudre ce problème pour nous-mêmes :

• @cloudflare/ci – Une nouvelle façon de gérer l’intégration et le déploiement continus (CI/CD) sur des millions de référentiels, capable de s’auto-réparer et de déployer des agents pour exécuter des tâches beaucoup plus complexes, basée sur Cloudflare Workflows.
• Traces OpenTelemetry dans l’environnement de développement local – Offre aux agents une observabilité comparable à celle dont ils disposent en production, intégrée dans Wrangler et le plugin Cloudflare Vite.
• Présentation : Cloudflare Agents et Agent Traces – Une nouvelle plateforme dédiée à l’observation, à la maintenance et à l’amélioration des agents, centrée sur les traces OpenTelemetry qu’ils génèrent.
• Comment Cloudflare utilise l’IA pour appliquer les normes d’ingénierie – Notre expérience de la mise en œuvre des pratiques exemplaires dans les référentiels et les spécifications de l’ensemble de nos produits et systèmes.
• Comment nous avons créé une « usine logicielle » pour ramener à zéro le nombre de tickets GitHub d’Astro – Notre expérience du développement de systèmes permettant de trier, reproduire, vérifier et corriger automatiquement les problèmes liés à un projet open source de grande ampleur et continuellement croissant.

Cependant, il y a quelque chose de plus important ici. Lorsque l’on examine le cycle de vie du développement logiciel, même avec la meilleure automatisation qui soit, ses postulats ne sont pas adaptés au volume de code que les agents peuvent écrire, ni à la rapidité avec laquelle les équipes de développement doivent évoluer pour rester compétitives. Nous pensons que l’heure est venue de remplacer le cycle de vie du développement logiciel (SDLC, Software Development Lifecycle) par le cycle de vie du développement des agents (ADLC, Agent Development Lifecycle).

La méthodologie SLDC est destinée aux équipes de développement logiciel. La méthodologie ADLC est destinée aux usines de logiciels.

En ce moment, le tout le monde parle du développement d’usines logicielles – des systèmes pilotés par des agents qui, à partir de données d’entrée, développent, améliorent, déploient et gèrent des logiciels de manière autonome. Prenez des données entrantes, qu’il s’agisse d’une erreur de production, d’un signalement de bug transmis par un client ou d’une idée de nouvelle fonctionnalité, et confiez-les entièrement à un agent.

Même lorsque des entreprises ont recours à des agents, la plupart des projets logiciels sont limités par des étapes nécessitant une intervention humaine : des opérateurs humains encouragent les agents, leur disent de continuer à travailler, leur demandent de tenir compte des commentaires issus d’une révision du code, surveillent continuellement une multitude d’agents et leur donnent des consignes. Dans la plupart des équipes de développement logiciel, ce sont toujours des humains qui gèrent chaque étape du modèle du cycle de vie du développement logiciel ; la seule différence est qu’ils délèguent les tâches que comporte chaque étape à un agent.

Le rêve qui sous-tend le concept des usines logicielles est donc le suivant : et si l’on repensait cette approche pour créer une « usine » couvrant l’intégralité du processus de développement logiciel ? Comment pouvons-nous permettre aux opérateurs humains de consacrer davantage de temps aux tâches qui nécessitent véritablement l’inspiration, le goût et le jugement humains ? Cela nous laisserait plus de temps pour concevoir, échanger avec nos clients et voir plus grand.

Une usine logicielle doit gérer les mêmes étapes du cycle de vie du développement logiciel, mais elle impose des exigences considérablement plus élevées à la plateforme sur laquelle elle repose. En effet, lorsque vous confiez les clés à l’agent, chaque étape manuelle qui dépendait auparavant d’un opérateur humain doit être adaptée pour devenir :

• Programmatique – Si l’approche « ClickOps » était déjà une mauvaise pratique pour les humains, c’est une option tout simplement exclue pour les agents. Chaque opération, sans exception, nécessite des API que les agents peuvent appeler et déboguer et sur lesquelles ils peuvent compter.
• Extensible horizontalement – Les déploiements en prévisualisation étaient un agrément intéressant lorsque des opérateurs humains passaient scrutaient un écran pendant le développement ou prenaient manuellement le contrôle d’un serveur de préproduction afin de localiser d’éventuels problèmes en amont de la mise en production. Pour que les agents fonctionnent correctement, chaque agent doit disposer de son propre aperçu correspondant à l’environnement de production.
• Reproductible – Que se passe-t-il si vous découvrez un bug qui peut uniquement être reproduit en simulant une connexion 4G sur un iPhone 15 ou qui n’affecte qu’une adresse IP située dans un pays bien particulier ? Les outils conventionnels de tests unitaires et de tests d’intégration ne sont d’aucune utilité dans ce cas de figure.
• En temps réel et basée sur des notifications push – Compter sur un opérateur humain pour examiner le bon tableau de bord a toujours été une approche peu recommandable pour savoir si tout fonctionne correctement ; avec des agents, toutefois, cette méthode devient totalement inefficace. Vous avez besoin d’un événement qui déclenche l’exécution d’une tâche par un agent.
• Atomique – Chaque modification doit pouvoir être testée, déployée, observée et annulée indépendamment, sans affecter les comportements non liés.
• Soumise à des autorisations – Vous savez pertinemment qu’il veut mieux éviter de le faire, mais aujourd’hui encore, vous confiez à quelques ingénieurs de confiance les clés d’accès SSH à l’environnement de production, au cas où les choses tourneraient vraiment au vinaigre. Il est impensable de laisser cette latitude à un agent, mais si celui-ci ne peut pas remonter l’information et obtenir davantage d’autorisations, comment peut-il faire son travail ?
• Dotée de capacités d’auto-amélioration – Les humains apprennent par l’expérience. Lors de leur premier déploiement de code ou de leur première permanence, les humains sont lents et ont besoin de travailler en binôme, mais ils finissent par s’améliorer et devenir plus rapides. Les agents, eux aussi, ont besoin de moyens pour tirer les leçons de leur expérience.

Nous devons innover si nous voulons sécuriser l’utilisation des usines logicielles pour la production de logiciels destinés à une utilisation réelle. Les usines logicielles se heurtent au même défi que d’autres systèmes autonomes, tels que les voitures autonomes : celui d’évoluer d’un taux de fiabilité de 80 % à un taux de 99 % suivi de plusieurs neuf.

Si vous souhaitez confier aux agents les clés du cycle de vie du développement logiciel, vous ne pouvez pas leur fournir un véhicule conçu pour des humains

Une voiture autonome est équipée de capteurs et de technologies dont un véhicule conventionnel ne dispose pas : des capteurs Lidar, des caméras, une puissance de calcul suffisante pour exécuter des inférences, ainsi qu’une connectivité à un système de commande central, capable de prendre le contrôle à distance si nécessaire.

Pour qu’un véhicule autonome atteigne 80 % des performances d’un conducteur humain, tous ces équipements ne sont probablement pas nécessaires. D'ailleurs, cela fait 10 ans que la conduite autonome a atteint des performances équivalentes à 80 % des capacités d’un conducteur humain. Toutefois, ce n’est le seuil que nous cherchons à atteindre : l’objectif est d’être bien plus performant et plus sûr qu’un conducteur humain. C’est ce que l’on attend lorsque l’on confie les clés à une machine, afin de pouvoir faire une sieste en toute sécurité pendant que la voiture circule à 130 km/h sur l’A6. Et c’est pourquoi les véhicules autonomes disposent de technologies spécialement conçues pour la conduite autonome : ce sont elles qui inspirent la confiance et permettent de gérer les scénarios particuliers qui ne peuvent pas être anticipés dès le départ.

Il en va de même pour les logiciels autonomes. Posez-vous la question : pourquoi n’avez-vous pas encore laissé votre agent approuver et fusionner automatiquement ses requêtes d’extraction dans vos services en production ? Cela ne fait aucun doute : plus les enjeux de ce que vous construisez sont importants, plus votre liste de raisons sera longue.

Lorsque l’on commence à examiner tout ce qui peut prendre un tournant dramatique pendant ce processus, mais également tout ce qui est nécessaire pour concevoir une solution adaptée aux clients, on prend conscience que l’ensemble est d’une complexité remarquable. Il ne s’inscrit pas dans une séquence linéaire d’étapes d’un fichier YAML dans GitHub Actions, et exige bien plus que l’exécution de tests automatisés classiques. Même une modification de moindre ampleur apportée à un tableau de bord peut impliquer une multitude de rôles, de spécialisations et de structures organisationnelles, et les modifications subjectives sont les plus difficiles à tester et à déléguer. La plupart de ces éléments ne font probablement pas encore partie de votre pipeline d’intégration continue/de livraison continue (CI/CD), à l’heure actuelle. Cependant, vous devrez les intégrer si vous souhaitez que ces projets voient le jour, tout en accordant un contrôle total aux agents qui gèrent l’usine logicielle.

Pour permettre aux agents de diriger l’ensemble du processus, nous avons besoin d’un meilleur moyen d’orchestrer ces successions d’étapes dynamiques. Nous pensons que la réponse est une instance Workflows capable de lancer des conteneurs, des agents et des navigateurs. Cette instance Workflows doit être capable de définir des indicateurs de fonctionnalités (feature flags) et de les activer pour un utilisateur test, d’analyser les journaux et les traces, de surveiller les paramètres de production pendant le déploiement progressif d’une modification et d’exécuter toutes les autres tâches nécessaires pour assurer un déploiement en toute sécurité.

Un pipeline CI/CD est simplement une instance Workflows ; toutefois, une instance Workflows peut être bien plus qu’un pipeline CI/CD.

Cloudflare Workflows vous permet d’enchaîner plusieurs étapes, de relancer automatiquement les tâches ayant échoué et de conserver l’état du système pendant plusieurs minutes, heures, voire semaines. Ces instances sont conçues pour coder des processus opérationnels complexes et dynamiques sous la forme d’un programme logique et compréhensible. Cet article de blog explique en détail pourquoi Workflows, utilisé conjointement à Artifacts, simplifie considérablement la définition et l’exécution des pipelines CI/CD. Par exemple :

import { CIWorkflow } from `@cloudflare/ci`

const deps: CiRunnerResult = await ci.runner({
      name: 'install',
      command: 'bun install --frozen-lockfile',
      cache: { inputs: ['package.json', 'bun.lock'] },
    });

    await Promise.all([
      deps.runner({ name: 'lint', command: 'bun run lint' }),
      deps.runner({ name: 'test', command: 'bun run test' }),
      deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
      deps.runner({ name: 'build', command: 'bun run build' }),
    ]);

    await deps.runner({
      name: 'deploy',
      command: 'bun wrangler deploy',
      cloudflareCredentials: {
        accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
      },
    });

Toutefois, les instances Workflows offrent bien plus qu’une simple succession d’étapes linéaires. Elles peuvent être définies dynamiquement, et elles peuvent déployer des agents ou d’autres instances Workflows. Cet exemple présente une instance Workflows qui examine les nouvelles données du jour précédent. L’instance Workflows dispose d’un contrôle total sur le moment et la manière dont l’agent est sollicité et peut transmettre le contexte d’une étape à l’autre :

import { WorkflowEntrypoint, type WorkflowEvent, type WorkflowStep } from 'cloudflare:workers';
import { init } from '@flue/runtime';
import { Reviewer } from './agents/reviewer.ts';
import { collectFindings } from './shared/nightly.ts';

type Params = { date: string };

export class NightlyReview extends WorkflowEntrypoint {
  async run(event: WorkflowEvent<Params>, step: WorkflowStep) {
    const findings = await step.do('collect findings', () => collectFindings(event.payload.date));

    const agent = init(Reviewer, { id: `nightly-${event.payload.date}` });

    const receipt = await step.do('dispatch review', () =>
      agent.dispatch(`Review these findings:\n${findings}`),
    );

    const review = await step.do('read review', async () => {
      const reply = await agent.read(receipt);
      return { text: reply.text, data: reply.data };
    });

    // ...
  }
}

Lorsque vous aurez intégré ce schéma et que vous serez, comme Cloudflare, « accro à Workflows », vous commencerez à vous demander : « Quelles autres tâches pourrais-je exécuter avec une instance Workflows ? Quelles autres étapes dont l’exécution est ralentie par l’intervention humaine pourrais-je déléguer à cette combinaison d’agents Workflow + Flue ? »

L’approche ADLC complète sur l’infrastructure Cloudflare

Lorsque l’on examine les étapes du cycle de vie du développement logiciel, avec Workflows, qui permet d’orchestrer des étapes complexes, et avec Artifacts, qui représente la couche de stockage du code, toutes les ressources nécessaires à un agent pour maîtriser l’ensemble du processus de développement, de déploiement et de maintenance d’un logiciel sont disponibles sur Cloudflare :

Composantes fondamentales pour construire votre usine logicielle

À l’heure actuelle, les pionniers de l’innovation construisent les usines logicielles de demain. À terme, les usines logicielles deviendront, à l’instar des agents et de l’IA, la manière habituelle de développer des logiciels. Pour la plupart des personnes et des entreprises, toutefois, nous n’en sommes pas encore là.

Et nous voulons y remédier.

Pour y parvenir, nous nous sommes posé les questions suivantes : comment rendre les choses simples et accessibles, afin que tous les internautes puissent bénéficier d’un changement de paradigme aussi important ? Et quelles sont les fonctionnalités fondamentales que nous pouvons mettre à la disposition de tous, de la plus petite start-up aux plus grandes plateformes du monde ?

Dans ce cas, nous pensons que les composantes fondamentales sont disponibles. Il nous reste encore du chemin à parcourir pour les connecter entre elles, pour continuer à développer notre propre usine logicielle et pour en tirer des enseignements, mais aujourd’hui, nous sommes prêts à vous aider à construire la machine qui construit la machine, sur Cloudflare. Commencez avec @cloudflare/ci, développez un agent et découvrez dans quelle mesure vous pouvez automatiser le cycle de vie du développement logiciel.