Rôles de développement

Le produit Développement regroupe les rôles qui construisent, révisent, testent et analysent de l'ABAP. Certains écrivent dans SAP ; plusieurs sont en lecture seule et ne peuvent physiquement pas le faire. Vous choisissez un rôle dans le compositeur de Chat ; si vous n'êtes pas sûr de celui qui convient, commencez par un rôle en lecture seule comme Recherche.

Cette page documente chaque rôle de Développement. Les rôles axés sur la construction (CDS, RAP, Fiori, Migration, Migration Map, Contrôle clean-core) ont leur propre page — voir CDS, RAP, Fiori et migration. Adobe Forms a aussi sa propre page — voir Adobe Forms.

Pour savoir comment les rôles appliquent les permissions au niveau des outils, voir Comment fonctionnent les rôles.

En un coup d'œil#

Développement#

Lecture/Écriture : Écriture. Le rôle par défaut.

Développement implémente une exigence de bout en bout. Sa méthodologie est délibérée : explorer le système → réutiliser d'abord (trouver et préférer les objets existants) → planifier le changement → verrouiller et définir le code source → valider (syntaxe + ABAP Unit + ATC) → activer → déverrouiller → rendre compte. Il ne supprime jamais rien, et il apporte le plus petit changement qui satisfait l'exigence.

Quand l'utiliser : le rôle de travail principal — à chaque fois que vous voulez qu'un changement soit réellement construit et activé dans SAP sous votre direction.

Architecture#

Lecture/Écriture : Lecture seule.

Architecture produit uniquement une conception de solution et un plan — les objets à créer ou modifier, les patterns à utiliser, le modèle de données, la stratégie de transport et les risques. Il n'écrit, ne verrouille ni n'active rien ; il vous remet un plan que vous pouvez réviser avant qu'aucune ligne de code ne soit écrite (par exemple, par une exécution Développement ultérieure).

Quand l'utiliser : au début d'une exigence non triviale, lorsque vous voulez vous accorder sur la forme de la solution avant de la construire.

Revue de code#

Lecture/Écriture : Lecture seule.

Revue de code lit vos objets cibles et les révise par rapport aux standards du projet. Il retourne des constats priorisés — Critique / Majeur / Mineur — chacun avec un emplacement et une suggestion de correction concrète. Il ne modifie rien. Lorsque la connexion le permet, la revue ne s'arrête pas à la lecture : elle exécute la vérification de syntaxe, l'ATC et les tests unitaires de l'objet et cite leur résultat, de sorte que chaque constat est étiqueté VERIFIED (un outil a produit la preuve) ou REASONED (établi par la lecture). Elle audite aussi les affirmations de sûreté du code lui-même — un commentaire promettant jamais ou toujours doit nommer ce qui l'applique — et, pour tout ce qui promet un aller-retour complet, indique ce qu'il peut lire face à ce qu'il peut réellement réécrire. Sur une connexion QA/PROD, les vérifications sont retenues par la garantie de lecture seule, et la revue le dit d'emblée.

Quand l'utiliser : pour vérifier un travail par rapport aux conventions de votre équipe, ou comme revue indépendante d'un changement avant qu'il ne progresse.

Tests unitaires#

Lecture/Écriture : Écriture — code de test uniquement.

Tests unitaires écrit ou étend des tests ABAP Unit pour la cible. Il ne modifie jamais la logique de production : s'il trouve un bug dans le code testé, il signale le bug plutôt que de modifier le code de production. Il exécute les tests jusqu'à ce qu'ils passent au vert.

Quand l'utiliser : pour ajouter ou étendre la couverture de tests sur du code existant sans aucun risque d'altérer le comportement.

C'est aussi ici que les questions ouvertes d'une revue de code sont tranchées. La revue est en lecture seule : lorsqu'un constat repose sur une hypothèse qu'un test peut confirmer ou infirmer, elle se termine par un bloc EXPERIMENT — l'affirmation, le test à écrire et ce que signifie chaque issue. Confiez ce bloc aux Tests unitaires : le test est écrit, exécuté, et l'issue obtenue est annoncée, y compris quand la réponse dérange. Un bloc qui exige un objet jetable ou une écriture dans le référentiel est refusé plutôt que glissé dans un test unitaire ; celui-là demande un rôle de développement.

Contrôle ATC#

Lecture/Écriture : Écriture.

Contrôle ATC exécute l'ABAP Test Cockpit sur la cible et rend compte des constats, regroupés pour la lisibilité. Il est léger : il corrige les constats uniquement si vous le demandez explicitement. Son pendant systématique est Remédiation ATC, ci-dessous.

Quand l'utiliser : un passage qualité rapide pour voir ce que signale ATC, sans s'engager à le corriger.

Remédiation ATC#

Lecture/Écriture : Écriture.

Remédiation ATC exécute ATC puis corrige les constats une catégorie à la fois — Performance, puis Sécurité, puis Robustesse, puis Propreté — en apportant des changements qui préservent le comportement et en re-contrôlant après chaque catégorie. Il exige et crée son propre transport dédié et n'emprunte jamais un transport existant.

Sur un système QAS ou PROD, il devient en lecture seule et se contente de rendre compte ; les écritures de remédiation sont réservées aux niveaux de développement.

Quand l'utiliser : un nettoyage systématique des constats ATC d'un objet, lorsque vous voulez que les corrections soient faites par passes disciplinées et vérifiables.

Recherche#

Lecture/Écriture : Lecture seule.

Recherche investigue et répond aux questions avec des preuves — il lit le code source, la structure et les informations d'utilisation, et il peut exécuter des requêtes SQL pour les questions de données. Il ne modifie rien. C'est un bon premier rôle, sûr, lorsque vous explorez un système inconnu.

Quand l'utiliser : toute question du type « comment cela fonctionne / où est-ce utilisé / que disent les données », sans aucun risque pour SAP.

Spécification#

Lecture/Écriture : Lecture seule vis-à-vis de SAP.

Spécification convertit une spécification client brute — texte collé, un fichier Excel, ou un .docx — en format de spécification interne normalisé de Makion. Il écrit uniquement des fichiers de spécification dans l'espace de travail (jamais dans SAP), avec versionnage, et alimente l'onglet Spécifications.

Quand l'utiliser : pour transformer une exigence entrante désordonnée en une spécification propre et structurée sur laquelle d'autres rôles (comme Estimation d'effort ou Développement) peuvent agir.

Estimation d'effort#

Lecture/Écriture : Lecture seule.

Estimation d'effort transforme une spécification en une estimation d'effort honnête : une tranche de complexité (S / M / L) par objet, des fourchettes d'heures plutôt que des chiffres uniques à fausse précision, des hypothèses et inconnues explicites, et une provision pour surcoût. Il produit un fichier d'estimation téléchargeable et n'écrit aucun code.

Quand l'utiliser : pour cadrer et chiffrer un travail à partir d'une spécification, avec l'incertitude énoncée d'emblée.

Pages associées#

• Comment fonctionnent les rôles — le modèle de permissions derrière chaque rôle.
• Chat — choisir un rôle et envoyer une tâche.
• CDS, RAP, Fiori et migration — les rôles de Développement de construction et de migration.
• Adobe Forms — cloner et adapter des formulaires interactifs SAP.
• Spécifications — où se trouve la sortie de Spécification.
• Méthodologie — personnaliser les règles de base que chaque rôle suit.
• Mode autonome — le pipeline d'application sous contrôle humain pour les écritures.