Agentic Software Development
Quand ça doit marcher.
Le codage agentique est transformateur — mais seulement quand il opère contre un modèle déterministe du système. Nous reconstruisons les applications héritées par codage agentique, ancré dans un modèle fiable, pour que le résultat tienne sur des systèmes que vous ne pouvez pas vous permettre de rater.
Ancré, pas en train de deviner
Pointez des agents sur un système non documenté et ils hallucinent, et une réponse fausse mais assurée sur un système central coûte cher. Nous leur donnons un modèle déterministe et sourcé contre lequel raisonner. Via Sysparency MCP, l’agent intègre lui-même le contexte métier : à quoi sert un programme, où il se situe dans le module et le processus, qui en dépend. C’est la différence entre une livraison agentique qui atterrit et une à laquelle vous ne pouvez pas vous fier.
Ce que l’agent obtient via Sysparency MCP
- Le contexte métier : le module, l’étape du processus et la finalité du programme, pas seulement ce qu’il fait.
- Chaque dépendance : appelants, tables écrites, interfaces sur les mêmes données.
- L’usage réel : à quelle fréquence, par qui, dialogue ou batch.
- Les preuves : chaque fait cité avec sa ligne source, pour que chaque changement soit vérifiable.
Ce que nous livrons
Reconstruire l’hérité par codage agentique
Reconstruisez une application héritée contre un modèle déterministe de son comportement réel — en préservant les règles qui comptent, en minimisant le risque.
IA agentique sur tout le SDLC
Intégrez des workflows agentiques dans la spécification, la génération, la vérification et la livraison — avec les humains aux commandes du changement critique.
Montez votre pipeline agentique
Mettez en place le pipeline de développement agentique au sein de votre organisation, sur vos systèmes et standards.
Exemple
Des transactions séparées vieilles de 25 ans. Un launchpad. Et un meilleur système.
Douze module pools SAP GUI d’une application legacy ont été transformés en un launchpad avec trois apps Fiori Elements, un tableau de bord et quatre objets métier RAP. Entièrement agentique : l’agent a compris les programmes legacy via Sysparency MCP et construit le nouveau système via SAP ADT MCP ; pas une seule ligne n’a été écrite à la main. L’ensemble issu du graphe a décidé ce qui serait construit autrement : les règles une fois dans le modèle de données au lieu de douze programmes, un parcours de clics au lieu de trois transactions, un run de réparation en moins, un champ mort en moins, quatre analyses en plus.
À gauche la liste des transactions des programmes legacy, à droite le launchpad qui les remplace, construit de bout en bout par un agent sans code écrit à la main. Application legacy sur un système d’essai.
- 12 → 4
- programmes → objets métier, un service OData
- 3 → 1
- transactions par réservation → un parcours de clics
- 0 → 7
- règles à l’enregistrement, au lieu d’un contrôle nocturne
- 0 → 4
- analyses : KPI, graphiques, classement, tendance
| Ce que l’ensemble a montré | Ce que c’est devenu | Preuve issue du graphe |
|---|---|---|
| Les dialogues ne sont pas les seuls à écrire dans la table des réservations. | Les objets métier deviennent l’entrée unique avec les règles ; BAPI, ALE et IDoc sont l’étape suivante, la liste existe déjà. | Écrivains selon le graphe : dialogue, groupe de fonctions SAPBC_GLOBAL_FIS, groupe BAPI, générateur ALE ; 35 modules RFC sur les mêmes tables. |
| Un contrôle nocturne répare ce que le point d’entrée ne valide pas. | Les contrôles d’existence des trois objets maîtres se déclenchent à l’enregistrement ; le run de contrôle est retiré. | Programme de contrôle avec usage 0 et lectures sur les trois tables maîtres ; ATC priorité 1 sur le dialogue de modification. |
| 73 % de tous les appels ne font qu’afficher. | Mode lecture par défaut, modification comme étape délibérée ; une liste de retrait avec preuves d’usage, l’indicateur fumeur obsolète supprimé. | Compteurs d’usage par transaction selon le graphe : 4 870 appels d’affichage contre 158 modifications d’agence. |
Construit sur des données de référence SAP dans un système d’essai, pas dans un système client. RFC, ALE et IDoc écrivent encore directement dans les tables ; c’est l’étape suivante documentée.
Demander le rapport de migration completPour les équipes plateforme IA
Sysparency comprend l’existant. Les outils SAP écrivent. Votre agent relie les deux.
Le serveur MCP de Sysparency expose le graphe de connaissances de votre code spécifique à tout client compatible MCP : Claude, ChatGPT, Copilot ou votre propre framework. L’agent lit des faits avec leurs preuves au lieu de deviner l’ABAP, et passe le relais aux outils ADT de SAP, qui génèrent, activent et transportent. Ajoutez les MCP de documentation SAP et l’agent consulte le standard pour chaque extension : ce que le standard offre aujourd’hui, ce qu’un programme Z ne fait que répliquer, où subsiste un véritable écart. Retour au standard et analyse des écarts, avec des preuves des deux côtés.
Sept outils en lecture seule
- Schéma du graphe
- Requête Cypher
- Recherche sémantique sur les descriptions métier
- Liste d’objets
- Métadonnées
- Lire le source
- Rechercher dans le source
Lecture seule, votre code uniquement
Tous les outils sont en lecture seule. Le graphe ne contient que votre customizing (Z, Y, vos namespaces), jamais le standard SAP.
Un environnement dédié par client
Le graphe et le serveur tournent dans un environnement dédié, accès via Microsoft Entra ID, hébergement UE ou votre propre infrastructure.
Intégré au rapport
Le dialogue de connexion se trouve dans l’en-tête du rapport : copiez l’URL, connectez votre client, posez vos questions.
Retour au standard, analyse des écarts
Sysparency MCP connaît l’existant de votre code spécifique, les MCP de documentation SAP connaissent le standard. Ensemble, l’agent trouve le remplacement standard d’une extension et documente l’écart qui subsiste.
Entre systèmes
Un agent, plusieurs systèmes SAP.
Chaque système reçoit son propre graphe de connaissances et son propre serveur MCP. Connectez-en deux ou plus à un seul agent et il travaille d’un système à l’autre : il compare les extensions, repère ce qui existe en double, montre où les copies ont divergé et ce qu’exige un déploiement de template ou une fusion. Chaque constat est sourcé dans les deux graphes.
- Comparer : le même objet Z dans deux systèmes, les différences jusqu’à la ligne.
- Consolider : quelles extensions peuvent devenir un template, lesquelles restent locales.
- Déployer : ce qui manque à un système cible avant qu’un template puisse y atterrir.
Questions sur la réingénierie agentique
Des réponses nettes.
Ce que les équipes plateforme et architecture demandent avant leur première reconstruction agentique.
Un agent IA comprend les programmes legacy via Sysparency MCP, décide avec l’ensemble ce qu’il faut construire autrement, et construit le nouveau système via SAP ADT MCP. Aucune ligne n’est écrite à la main.
Sans lui, l’agent voit un fichier et devine le reste. Avec le graphe, il connaît chaque écrivain d’une table, chaque appelant, l’usage réel et le sens métier, chacun sourcé à la ligne.
Tout client compatible MCP : Claude, ChatGPT, Copilot ou votre propre framework. Les sept outils sont en lecture seule et ne couvrent que votre propre code.
Oui. Avec les MCP de documentation SAP connectés, l’agent consulte ce que le standard offre aujourd’hui, ce qu’un programme Z ne fait que répliquer et où subsiste un véritable écart.
C’est une application legacy sur un système d’essai SAP, pas un système client. Douze module pools sont devenus un launchpad avec trois apps Fiori Elements, un tableau de bord et quatre objets métier RAP.
Continuer l’exploration
Reconstruisez en confiance
Parlons d’une reconstruction agentique et ancrée.