Dans le chat, vous choisissez un rôle pour chaque requête. Un rôle est à la fois une méthodologie complète et une limite d'accès : les rôles en lecture seule reçoivent physiquement uniquement les outils de lecture SAP et ne peuvent rien modifier. Tout rôle de Support et de Conseil est en lecture seule ; seuls les rôles de Développement écrivent, et uniquement sur un système de niveau développement. Un administrateur peut redéfinir n'importe quel rôle ou ajouter le sien.
Réalise une exigence de bout en bout : comprendre → explorer l'état actuel → réutiliser l'existant → planifier → lock + set source → syntax check + tests/ATC → activer → compte rendu.
Une modification finalisée et activée selon votre approche, plutôt qu'un brouillon de code.
Produit une conception de solution, n'écrit aucun code.
Un plan réfléchi avant que quiconque ne touche au système.
Revue au regard de vos standards ; constats classés par priorité (Critical / Major / Minor) avec localisations exactes et corrections.
Une deuxième passe indépendante — sans le risque que le relecteur réécrive « accidentellement » quelque chose.
Écrit/étend des tests ABAP Unit ; ne modifie jamais la logique de production pour « forcer » un test au vert.
Une couverture de tests sans distordre la logique métier.
Exécute l'ABAP Test Cockpit, restitue les constats classés par priorité ; ne corrige que si vous le demandez explicitement.
La qualité au standard ATC sous votre contrôle.
Exécute l'ATC et corrige les constats méthodiquement, catégorie par catégorie, sans changer le comportement.
Des constats soldés sans changer ce que fait le code.
Investigue et répond avec des preuves, peut exécuter des requêtes SQL sur les données.
Des réponses rapides et fondées sur le système — sans risque pour lui.
Transforme la spécification brute d'un client dans le format standardisé interne de Makion, en la confrontant au système en production.
Une exigence chaotique devient un cahier des charges ordonné et testable.
Chiffre un développement à partir de sa spécification : chaque objet noté S / M / L avec une fourchette d'heures, plus les hypothèses et les inconnues derrière le chiffre. Fournit un document d'estimation.
Un chiffrage défendable avant de vous engager, plutôt qu'une intuition.
Conçoit et construit des modèles de données CDS dans le style VDM de SAP : entités de vue interface et consumption, associations, annotations et contrôle d'accès (DCL), créés et activés sur votre système.
Un modèle de données propre et en couches sur lequel vos rapports et vos applications se construisent, plutôt qu'un SELECT ponctuel.
Construit des objets métier RESTful ABAP (RAP) de bout en bout : modèle CDS, behavior definition et behavior class, projection et binding de service OData — activés et prêts à consommer.
Un vrai service transactionnel sur votre système, pas le schéma d'un service.
Rend un service prêt pour Fiori Elements : les annotations @UI et les extensions de métadonnées qui pilotent un List Report / Object Page, plus le binding de service OData — puis remet honnêtement le déploiement de l'app-shell UI à votre outillage.
Vos données à un pas d'une application Fiori — toute la couche d'annotations réalisée pour vous.
Prend un objet spécifique, trouve ce qui casse sur S/4HANA (API obsolètes, accès direct aux tables, ancienne syntaxe) et propose un correctif minimal pour chacun ; vous approuvez, il applique et active, et pour les changements risqués il écrit d'abord un test de verrouillage.
ABAP spécifique prêt pour S/4HANA / Clean-Core, objet par objet — sur votre propre ECC.
La moitié analyse de la migration : lit votre code spécifique et son usage pour cartographier l'effort S/4HANA — ce qui est utilisé, ce qui casse, ce qu'il faut corriger en premier. Elle ne se connecte jamais à la production.
Une vue de migration priorisée avant que quiconque ne change une ligne.
Lit un SAP Adobe Form existant et applique une modification structurelle (ajouter / retirer / réordonner / relier une colonne), et renvoie un XDP prêt à coller pour l'onglet « XML Source » de SFP ; la géométrie et les liaisons de données sont garanties par un moteur déterministe.
Modifie les Adobe Forms en décrivant le changement plutôt qu'à la main dans LiveCycle.
Audite la conformité clean core : API released, aucune lecture de tables standard, extensibilité. En lecture seule.
Un verdict clean core par objet avant d'écrire le plan de migration.
Trie un incident à travers les dumps ST22, les jobs SM37, les logs SLG1, les mises à jour SM13, les IDoc et le tRFC — et renvoie des causes racines classées avec une seule action suivante typée.
De « c'est cassé » à une cause classée et une étape suivante — en lecture seule.
Un balayage matinal du système : IDoc bloqués, jobs en échec, arriéré tRFC/qRFC et dumps récents — l'état de santé avant que les utilisateurs ne le signalent.
Les problèmes détectés avant l'arrivée du premier ticket.
Une analyse approfondie des échecs d'IDoc : enregistrements de statut, données de contrôle et segments (EDIDC / EDIDS / EDID4), pour expliquer pourquoi l'un a échoué et quoi faire. Le retraitement reste une remise.
La vraie raison de l'échec d'un IDoc, pas seulement un numéro de statut.
Analyse de l'état actuel dans un format fixe : constat → preuve → impact → recommandation → charge / risque. Lit le système et le code, ne modifie rien.
Un état des lieux honnête, appuyé par des preuves.
Déduit du code les autorisations dont un programme a réellement besoin, les compare à celles qui sont accordées, et signale les manques et les octrois excessifs.
Un raisonnement du moindre privilège ancré dans le code réel.
Inventorie le paysage d'intégration (RFC, ALE, IDoc, OData) à partir de la configuration et du code (statique, pas à l'exécution), pour que rien ne soit oublié lors d'une migration ou d'un audit.
Une cartographie complète des interfaces, lue depuis le système lui-même.
Assemble un livrable de mission (constats, feuille de route et un verdict GO / NO-GO) à partir du travail réalisé par les autres rôles de conseil.
Un rapport prêt pour le client, pas un tas de notes.
Les rôles en lecture seule ne peuvent pas écrire au niveau des outils, pas seulement au niveau du prompt. Un administrateur peut redéfinir la méthodologie de n'importe quel rôle ou en ajouter de nouveaux. Chaque rôle appartient à un produit, et tout rôle en dehors de Development est en lecture seule au niveau des outils. La même IA gouvernée, le même canal ADT officiel, les mêmes garanties de lecture seule, présentés comme trois produits — et les trois sont inclus dans une seule licence.
Votre SAP, vos standards, vos conditions.
Plusieurs développeurs ou un déploiement client ? Équipes et entreprises