Les entreprises bloquées par des systèmes REST obsolètes peuvent enfin sauter dans l'ère des agents autonomes. La solution ? Des couches ultra-fines qui transforment vos services existants en agents A2A, sans tout casser.

UNE RÉVOLUTION DISCRÈTE MAIS INCONTOURNABLE

Imaginez un monde où vos vieux services web, ceux qui tournent depuis des années sur des API REST bien rodées, pourraient soudainement discuter avec des agents autonomes. Pas besoin de tout réécrire, pas besoin de déployer une nouvelle infrastructure parallèle. Juste une fine couche de code qui fait le lien entre l'ancien et le nouveau.

C'est exactement ce que propose une collaboration entre AWS et des chercheurs : les superpositions agentiques. Ces couches ultra-légères transforment vos services REST classiques en agents A2A capables de communiquer avec d'autres agents, de raisonner et de coordonner des tâches complexes. Le tout sans toucher à la logique métier existante.

Les entreprises peuvent enfin ajouter des capacités A2A à leurs services existants sans réécrire une ligne de code métier, sans dupliquer leur code, et sans lancer de nouvelles infrastructures parallèles.

REST VS A2A : DEUX MONDES QUI NE SE PARLENT PAS

Les API REST sont comme des distributeurs automatiques : vous insérez une pièce (vos paramètres), vous appuyez sur un bouton, et vous recevez un produit fini (la réponse). C'est simple, direct, et ça marche très bien pour des opérations basiques comme créer, lire, mettre à jour ou supprimer des données.

Mais les agents autonomes, eux, fonctionnent différemment. Ils doivent pouvoir découvrir d'autres agents, négocier des capacités, échanger des messages structurés et coordonner des tâches en plusieurs étapes. L'A2A (Agent-to-Agent) est le nouveau protocole qui permet cette communication entre agents. Là où REST optimise la stabilité et l'exécution directe, A2A optimise le raisonnement, la coordination et la collaboration entre services.

Le problème ? Les deux systèmes sont basés sur des paradigmes opposés. Résultat : les entreprises se retrouvent coincées avec des services REST qui ne peuvent pas participer à l'écosystème A2A moderne. Et migrer tout vers A2A coûterait des fortunes en réécriture et en infrastructure parallèle.

LE DÉFI : INTÉGRER LES AGENTS EXISTANTS SANS TOUT CASSER

Avant que le protocole A2A ne soit standardisé, les entreprises déployaient souvent leurs agents comme des services REST classiques. Le problème ? Ces agents ne sont pas natifs A2A. Résultat : aujourd'hui, des centaines de services existants ne peuvent pas communiquer avec les nouveaux agents autonomes. Et les réécrire intégralement serait un cauchemar logistique et financier.

La solution ? Une approche pragmatique : les superpositions agentiques. Ces couches minces agissent comme des traducteurs entre le monde REST et le monde A2A. Elles permettent d'ajouter des capacités A2A à des services existants sans toucher à leur cœur de métier, sans dupliquer le code, et sans lancer de nouvelles infrastructures parallèles.

COMMENT ÇA MARCHE ? UN EXEMPLE CONCRET AVEC UN CALCULATEUR

Prenons un exemple simple : un service de calculatrice REST qui répond à des requêtes comme POST /api/v1/calculate avec un JSON comme { "operation": "add", "operands": [5, 3] }. Pour transformer ce service en agent A2A, on va lui ajouter une superposition agentique qui comprend le protocole A2A.

Cette superposition ajoute plusieurs éléments clés :

  • • Une carte d'agent (agent card) accessible via GET /.well-known/agent-card.json qui décrit les capacités de l'agent.
  • • Un endpoint A2A standardisé POST /a2a qui accepte des messages au format JSON-RPC 2.0.
  • • Des méthodes comme SendMessage et SendStreamingMessage pour échanger des messages structurés.

Le tout sans modifier le code original de la calculatrice. La superposition se charge de traduire les messages A2A en appels REST classiques et inversement.

LA CARTE D'AGENT : LA PIÈCE MAÎTRESSE DU PUZZLE

La carte d'agent (agent card) est un fichier JSON qui décrit les capacités de l'agent. Dans notre exemple de calculatrice, elle ressemble à ceci :

{
  "name": "Calculator Agent",
  "description": "Simple calculator supporting basic arithmetic operations",
  "supportedInterfaces": [
    {
      "url": "http://localhost:5000/a2a",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "0.3"
    }
  ],
  "provider": {
    "organization": "Example Organization",
    "url": ""
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": false,
    "pushNotifications": false,
    "extendedAgentCard": false
  },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": []
}

Ce fichier est accessible via l'URL /.well-known/agent-card.json et permet à d'autres agents de découvrir et de comprendre comment interagir avec notre calculatrice transformée en agent.

TRADUIRE LES MESSAGES A2A EN APPELS REST : LE PATRON DU TRADUCTEUR

La superposition agentique doit transformer les messages A2A en appels REST classiques. Par exemple, un message A2A comme celui-ci :

{
  "message": {
    "parts": [{
      "kind": "data",
      "data": {
        "operation": "add",
        "operands": [5, 3]
      }
    }]
  }
}

Doit être converti en un appel REST vers /api/v1/calculate avec le payload { "operation": "add", "operands": [5, 3] }. C'est le rôle de la fonction extractmessagepayload() qui extrait les données utiles du message A2A.

Une fois la réponse REST reçue, la superposition la reformate en un message A2A standardisé grâce à la fonction builda2amessage(). Le résultat final est un message structuré que d'autres agents peuvent comprendre et utiliser.

GÉRER LES ERREURS COMME UN PRO : LE PROTOCOLE JSON-RPC

Pour que tout fonctionne, la superposition doit respecter le protocole JSON-RPC 2.0, un standard qui définit comment les messages doivent être formatés et comment les erreurs doivent être gérées. Voici les codes d'erreur possibles :

PARSE_ERROR = -32700  # Erreur de parsing du message
INVALID_REQUEST = -32600  # Requête invalide
METHODNOTFOUND = -32601  # Méthode non trouvée
INVALID_PARAMS = -32602  # Paramètres invalides
INTERNAL_ERROR = -32603  # Erreur interne

La fonction jsonrpc_error() permet de construire une réponse d'erreur standardisée, tandis que jsonrpc_success() génère une réponse de succès. Par exemple, si un message A2A ne contient pas de données valides, la superposition renvoie :

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32602,
    "message": "Invalid params: No data found in message.parts."
  },
  "id": "12345"
}

LA FONCTION CLÉ : DELEGUER LES MESSAGES A2A AUX ENDPOINTS REST

La fonction handlesendmessage() est le cœur de la superposition. Elle reçoit un message A2A, extrait les données utiles, et les transmet à l'endpoint REST approprié. Voici comment elle fonctionne :

def handlesendmessage(data: Dict) -> Tuple[Any, int]:
    request_id = data.get("id")
    params = data.get("params", {})
    message = params.get("message", {})
    contextid = message.get("contextId") or generateid()
    messageid = generateid()

    payload = extractmessagepayload(message)
    if not payload:
        return jsonify(jsonrpc_error(
            JsonRpcError.INVALID_PARAMS,
            "Invalid params: No data found in message.parts.",
            requestid=requestid
        )), 400

    restresponse, status = invokerest_endpoint(
        endpoint="/api/v1/calculate",
        json_data=payload,
        http_method="POST"
    )

    if 200 <= status < 300:
        a2a_message = build_a2a_message(message_id, context_id, rest_response)
        return jsonify(jsonrpc_success(a2a_message, request_id)), 200
    else:
        error_message = "Operation failed"
        if isinstance(rest_response, dict):
            error_message = (rest_response.get("error")
                             or rest_response.get("details")
                             or "Operation failed")
        error_code = (JsonRpcError.INVALID_PARAMS if 400 <= status < 500
                      else JsonRpcError.INTERNAL_ERROR)
        return jsonify(jsonrpc_error(
            error_code, error_message,
            data=rest_response, request_id=request_id
        )), status

Cette fonction ne fait que transmettre les messages sans les analyser ni les router. Elle extrait le payload, l'envoie au service REST, et reformate la réponse en message A2A. Simple, efficace, et surtout : sans toucher au code métier existant.

CONFIGURER LES ROUTES A2A SUR UNE APPLICATION FLASK

Pour que l'application Flask comprenne le protocole A2A, il faut ajouter des routes spécifiques. Voici comment configurer ces routes :

def setupa2aroutes(app: Flask) -> None:
    app.addurlrule("/.well-known/agent-card.json", "getagentcard",
                     getagentcard, methods=["GET"])
    app.addurlrule("/a2a/capabilities", "get_capabilities",
                     get_capabilities, methods=["GET"])
    app.addurlrule("/a2a/health", "a2a_health",
                     a2a_health, methods=["GET"])
    app.addurlrule("/a2a", "a2a_jsonrpc",
                     handlejsonrpc, methods=["POST"])
    logger.info("A2A Protocol v0.3 routes registered")

Ces routes permettent à l'application de répondre aux requêtes A2A standardisées :

  • GET /.well-known/agent-card.json : renvoie la carte d'agent.
  • GET /a2a/capabilities : liste les capacités de l'agent.
  • GET /a2a/health : vérifie l'état de santé de l'agent.
  • POST /a2a : endpoint principal pour envoyer et recevoir des messages A2A.

UNE APPLICATION FLASK COMPLÈTE : LE CODE QUI FAIT TOUT MARCHER

Voici comment structurer une application Flask complète avec une superposition agentique. Le fichier main.py initialise l'application et enregistre les routes REST existantes ainsi que les nouvelles routes A2A :

from flask import Flask
from app.restapi import restapi
from app.a2aadapter import setupa2a_routes

def create_app():
    app = Flask(__name__)

    # Enregistrer l'API REST existante
    app.registerblueprint(restapi)

    # Ajouter le support du protocole A2A
    setupa2aroutes(app)
    app.logger.info("A2A Protocol enabled via Request Translator Pattern")

    return app

Ce code montre comment intégrer une superposition agentique dans une application existante sans modifier son fonctionnement actuel. La logique métier reste inchangée, mais l'application peut désormais participer à l'écosystème A2A.

INSTALLER ET LANCER L'APPLICATION : LE GUIDE PAS À PAS

Pour déployer cette superposition agentique, voici les étapes à suivre :

python -m venv venv
source venv/bin/activate  # Sur Windows : venv\Scripts\activate
pip install -r requirements.txt
python -m app.main

Une fois l'application lancée, elle est accessible via les endpoints REST classiques et les nouveaux endpoints A2A. Les agents autonomes peuvent désormais interagir avec votre service de calculatrice comme s'il s'agissait d'un agent natif.

LES BÉNÉFICES CONCRETS : POURQUOI ÇA VA TOUT CHANGER

Les superpositions agentiques offrent plusieurs avantages majeurs pour les entreprises :

  • Réduction de l'empreinte agentique : plus besoin de déployer des infrastructures parallèles pour chaque nouvel agent. Les services existants sont réutilisés comme des agents.
  • Compatibilité totale : les services REST classiques peuvent désormais participer à des workflows multi-agents complexes.
  • Pas de réécriture : la logique métier reste intacte. Seule la couche de communication est ajoutée.
  • Simplicité de déploiement : une seule pipeline de déploiement pour les endpoints REST et A2A, sur le même hôte et le même port.
  • Évolutivité : les services peuvent être mis à l'échelle pour gérer le trafic supplémentaire généré par les interactions A2A.
Cette approche réduit l'empreinte agentique dans l'infrastructure en réutilisant les services existants comme des agents, sans duplication de code ni infrastructures parallèles.

COMPARAISON : SUPERPOSITION AGENTIQUE VS AUTRES APPROCHES

Il existe plusieurs façons d'ajouter des capacités A2A à un service existant. Voici les principales approches et leurs avantages/inconvénients :

1. MAINTENANCE DE DEUX STACKS SÉPARÉS (REST + A2A)

Cette approche consiste à développer et maintenir deux interfaces distinctes pour exposer les mêmes capacités : une en REST et une en A2A. Les deux stacks partagent la même logique métier, mais ont des contrôleurs et des gestionnaires différents.

Avantages :

  • • Pas besoin de modifier l'API REST existante.
  • • Les clients peuvent choisir leur protocole préféré.

Inconvénients :

  • • Complexité accrue : deux stacks à maintenir, tester et déployer.
  • • Risque de divergences entre les deux interfaces.
  • • Coût opérationnel plus élevé.

2. RÉORGANISATION DE L'API REST EXISTANTE

Cette approche consiste à refactorer l'API REST existante pour qu'elle puisse être réutilisée par une nouvelle interface A2A. La logique métier est extraite dans des services partagés, et les contrôleurs sont mis à jour pour appeler ces services.

Avantages :

  • • Une seule interface à maintenir.
  • • Réduction de la duplication de code.

Inconvénients :

  • • Risque élevé de régressions et de comportements inattendus.
  • • Charge de test accrue.
  • • Nécessite de modifier le code existant, ce qui peut introduire des bugs.

3. SUPERPOSITION AGENTIQUE (LA SOLUTION RECOMMANDÉE)

La superposition agentique ajoute une fine couche de code qui traduit les messages A2A en appels REST et inversement. Aucune modification de la logique métier n'est nécessaire.

Avantages :

  • • Pas de réécriture de code métier.
  • • Pas de duplication de code.
  • • Pas d'infrastructure parallèle.
  • • Une seule pipeline de déploiement pour REST et A2A.
  • • Réduction de l'empreinte agentique dans l'infrastructure.

Inconvénients :

  • • Nécessite une compréhension du protocole A2A.
  • • Peut introduire une légère latence due à la traduction des messages.

UN CAS D'USAGE PRATIQUE : L'AGENT SUPERVISEUR

Les superpositions agentiques sont particulièrement utiles pour les agents superviseurs. Ces agents ont besoin de coordonner plusieurs services, dont certains peuvent être des API REST classiques. Par exemple, un agent superviseur pourrait :

  • • Classifier une intention (par exemple, "calculer une somme").
  • • Router la demande vers le bon service (la calculatrice).
  • • Recevoir le résultat et le transmettre à l'utilisateur final.

Avec une superposition agentique, l'agent superviseur peut interagir avec la calculatrice comme s'il s'agissait d'un agent natif A2A, sans avoir à gérer les détails techniques des appels REST.

INTÉGRATION AVEC AMAZON BEDROCK AGENTCORE GATEWAY

Pour les entreprises utilisant Amazon Bedrock, il existe une solution encore plus simple : Amazon Bedrock AgentCore Gateway. Ce service permet de construire, connecter et optimiser des agents à grande échelle sans gérer l'infrastructure. L'AgentCore Gateway peut découpler la superposition agentique de l'application principale, ce qui simplifie encore plus le déploiement et la maintenance.

Voici comment cela fonctionne :

  • • L'application principale expose ses capacités via des API REST classiques.
  • • L'AgentCore Gateway ajoute la couche A2A par-dessus, sans modifier l'application.
  • • Les agents autonomes peuvent interagir avec l'application via l'AgentCore Gateway, comme s'il s'agissait d'un agent natif.
Amazon Bedrock AgentCore Gateway permet de découpler la superposition agentique de l'application principale, simplifiant ainsi le déploiement et la maintenance.

LE FUTUR DES ENTREPRISES : UN MONDE OÙ TOUT EST AGENT

Les superpositions agentiques ne sont pas une simple astuce technique. Elles représentent une évolution majeure dans la façon dont les entreprises conçoivent et déploient leurs services. Avec cette approche, les entreprises peuvent :

  • • Moderniser leurs services existants sans tout casser.
  • • Participer à l'écosystème A2A sans déployer de nouvelles infrastructures.
  • • Réduire les coûts et la complexité opérationnelle.
  • • Préparer leurs systèmes pour l'avenir, où les agents autonomes joueront un rôle central.

Le message est clair : il est temps d'arrêter de reconstruire et de commencer à superposer. Les superpositions agentiques offrent une voie pragmatique pour intégrer les agents autonomes dans les entreprises, sans tout réécrire ni tout casser.

VERDICT : UNE SOLUTION PRAGMATIQUE POUR UNE TRANSITION DOUCE

Les superpositions agentiques sont bien plus qu'une solution technique : c'est une révolution discrète qui permet aux entreprises de faire le pont entre deux mondes. D'un côté, les API REST stables et éprouvées. De l'autre, les agents autonomes et leur protocole A2A. En ajoutant une fine couche de code, les entreprises peuvent transformer leurs services existants en agents A2A, sans tout réécrire, sans tout casser, et sans exploser leur budget.

Cette approche réduit la complexité opérationnelle, limite les risques, et prépare les entreprises pour l'avenir. Dans un monde où l'automatisation et l'intelligence artificielle deviennent omniprésentes, les superpositions agentiques offrent une solution pragmatique pour intégrer ces nouvelles technologies sans tout bouleverser.

Le message final ? Si votre entreprise utilise encore des API REST classiques, il est temps de réfléchir à comment les transformer en agents A2A. Et les superpositions agentiques sont la clé pour y parvenir, rapidement et efficacement.

Sources :
  • AWS ML Blog

L'indépendance de CLODCO est votre garantie.

Pour que l'actualité de l'IA reste sans filtre et sans concession, votre soutien est indispensable. Votre contribution est le seul moteur de notre liberté éditoriale.

Soutenir CLODCO