IA et développement ABAP : pourquoi le « 100 % IA » ne suffit pas

Chez Kaï Consulting, nous utilisons l'IA dans notre quotidien de développeurs et de Tech Leads SAP. Notre position n'est donc pas de l'écarter, mais de distinguer les tâches où elle nous aide de la responsabilité qu'on ne peut pas lui déléguer.

Nous faisons évoluer les outils utilisés selon leur pertinence pour nos usages. Cet article expose notre pratique et notre position à la date de publication, pas un benchmark universel ni une promesse de gain de productivité.

Pourquoi le développement « 100 % IA » ne suffit pas

Confier une spécification fonctionnelle à un assistant et lui demander de produire seul tout le développement est séduisant. Il peut générer une structure, des classes, des appels et des tests qui semblent cohérents. Mais cette apparence ne garantit pas une solution correcte dans le système SAP cible.

Une spécification décrit un besoin. Elle ne contient pas nécessairement tous les choix techniques : version du système, objets existants, extensions autorisées, autorisations, comportement transactionnel, interfaces, volumes ou contraintes d'exploitation. Ces éléments doivent être découverts, discutés et validés.

Une IA peut réussir un exercice isolé ou une tâche bien bornée. Ce que nous ne jugeons pas fiable aujourd'hui, c'est de transformer cette réussite en promesse de livraison autonome d'une application métier complète. Le développeur doit encore cadrer, vérifier, corriger et intégrer la proposition.

Les hallucinations : du plausible au faux

Dans nos usages ABAP, le problème est notamment celui des références inventées ou mal comprises : module de fonction inexistant, classe absente, méthode imaginaire, paramètres incorrects ou confusion entre plusieurs contextes SAP. Un nom qui respecte les conventions peut sembler convaincant sans correspondre à un objet réellement utilisable.

Il faut distinguer deux difficultés. L'objet inventé n'existe pas. L'objet inadapté peut exister ailleurs, mais ne pas être disponible dans la version cible ou autorisé dans le modèle de développement retenu. Dans les deux cas, il faut vérifier la proposition dans le système et sa documentation, pas demander seulement à l'IA de confirmer sa propre réponse.

SAP indique dans ses recommandations sur l'IA générative en ABAP que des hallucinations sont possibles et que les objets ou extraits générés doivent être revus par des développeurs humains. Cette recommandation concerne les capacités ABAP de Joule ; elle ne constitue pas un test des assistants que nous utilisons.

Et un programme qui compile peut encore être faux : mauvaise règle métier, autorisation oubliée, doublons, traitement d'erreur incomplet ou résultats différents sur des cas limites. La compilation est une vérification nécessaire, pas une validation de livraison.

Les usages qui nous sont réellement utiles

La distinction importante n'est pas « IA ou pas IA ». C'est la taille de la tâche, le contexte disponible et notre capacité à vérifier le résultat. Sur un périmètre précis, l'assistant devient un interlocuteur technique utile.

Revue de code : un regard complémentaire

Sur une méthode ou un traitement existant, l'IA peut proposer des points d'attention : conditions redondantes, logique difficile à lire, gestion d'erreurs, cas limites ou découpage des responsabilités. Nous pouvons confronter ses remarques au code et au besoin.

Elle aide à préparer une revue, mais ne certifie pas le code. Elle peut aussi signaler un faux problème ou manquer une anomalie. Les constats doivent être confirmés par le développeur et complétés par les contrôles adaptés, notamment ATC et la revue humaine.

Optimisation d'algorithmes : des pistes à mesurer

Une boucle imbriquée, une recherche répétée dans une table interne ou un calcul inutilement recomposé sont de bons sujets de discussion. L'IA peut aider à comparer des approches et à expliciter leurs compromis.

La décision ne se prend pas sur la seule élégance du code proposé. Il faut préserver le comportement fonctionnel, contrôler les cas limites et mesurer sur des données représentatives. Quand le coût vient des accès à la base, les outils d'analyse du système restent indispensables. Notre approche de l'optimisation ABAP et HANA suit cette logique.

Documentation : structurer et expliquer

À partir d'un code et de décisions connus, l'IA peut préparer une explication, une documentation de méthode ou une synthèse pour une passation. Elle aide à transformer des éléments techniques en un document plus lisible.

La relecture doit retirer les intentions qu'elle aurait déduites à tort et vérifier les règles décrites. Une documentation fluide mais incorrecte rend la maintenance plus difficile. Elle doit distinguer ce que le code fait de ce que le métier attend.

Rétro-ingénierie : comprendre avant de modifier

Sur un programme peu documenté, l'IA peut aider à reconstruire le cheminement apparent : entrées, transformations, sorties, branches et dépendances visibles. C'est utile pour formuler des questions et préparer une investigation.

Mais un extrait ne raconte pas tout le système. Paramétrage, traitements appelants, extensions et usages réels peuvent manquer. Les conclusions restent des hypothèses à confronter aux objets SAP, à l'exécution et aux personnes qui connaissent le processus.

Tests unitaires : préparer les cas, pas définir seule la vérité

L'IA peut suggérer des scénarios ABAP Unit, des jeux de données et un premier squelette de tests. Elle est utile pour explorer les entrées vides, erreurs, doublons et autres situations auxquelles on ne pense pas spontanément.

Les résultats attendus doivent toutefois venir du besoin validé. Si l'IA écrit le code puis les tests à partir du même raisonnement erroné, les tests peuvent reproduire l'erreur au lieu de la détecter. Il faut vérifier leurs assertions, les exécuter et compléter la couverture par les tests d'intégration et métier nécessaires.

Un exemple pédagogique : relire un traitement existant

Le cas suivant illustre la démarche ; il ne décrit pas une mission client ni un résultat mesuré.

Un programme rapproche des lignes de documents au moyen de boucles imbriquées. Plutôt que de demander « réécris tout le programme », on fournit un extrait autorisé, le comportement attendu et les contraintes connues.

1. Demande ciblée : repérer les recherches répétées et proposer une autre organisation, sans changer les règles de rapprochement.
2. Proposition de l'IA : préparer une structure de recherche indexée et préciser les hypothèses sur les clés.
3. Vérification humaine : contrôler si les clés sont réellement uniques. Une proposition qui écrase les doublons peut changer le résultat métier.
4. Validation : adapter le code, tester les cas concernés et comparer les résultats et les temps de traitement sur un volume représentatif.

L'intérêt est dans l'exploration d'une solution et la discussion qu'elle ouvre. La décision finale repose sur le contexte, les tests et la mesure, pas sur l'assurance avec laquelle l'assistant présente sa réponse.

Notre règle : cadrer, vérifier, tester

Nous privilégions une demande délimitée, avec un résultat que l'équipe peut contrôler :

• Cadrer : préciser l'objectif, la version cible, le modèle de développement et les contraintes connues. Demander à l'outil de distinguer ses hypothèses des éléments fournis.
• Vérifier : confirmer l'existence et la disponibilité des objets, la signature des appels et les règles d'usage des API. Vérifier une proposition ABAP Cloud dans son contexte, et non comme du code ABAP générique.
• Relire : examiner le métier, les autorisations, les erreurs, les transactions et les effets sur les autres traitements.
• Tester : exécuter les contrôles statiques, les tests unitaires et les tests d'intégration pertinents. Mesurer une optimisation avant de l'adopter.
• Assumer : garder un responsable humain du code livré et des décisions documentées.

Nous utilisons l'IA pour challenger et préparer notre travail. Nous ne lui déléguons pas la validation de ce que nous livrons.

La confidentialité fait partie du cadre

Un extrait de code peut révéler une logique métier, des noms internes, des données ou des secrets. Son utilisation dans un assistant doit respecter les règles du client, les engagements du projet et les outils autorisés.

Il faut vérifier les conditions de traitement et de conservation des données, les accès et les possibilités de réutilisation avant de transmettre du contenu. Retirer les noms ne suffit pas toujours à rendre un extrait partageable. Sans cadre autorisé, on reste sur un exemple synthétique et non confidentiel.

Ce que cela signifie pour les projets et pour l'équipe

Pour une DSI ou un partenaire intégrateur, notre position est simple : l'usage de l'IA n'efface ni le cadrage, ni la revue technique, ni la validation métier. Une livraison se juge sur son comportement et sa maintenabilité, pas sur le fait qu'un assistant a écrit une partie du code.

Pour les développeurs qui souhaitent nous rejoindre, l'IA a sa place dans le travail d'équipe : explorer, comparer, expliquer et apprendre. Garder un regard critique sur ses réponses fait partie du métier de développeur et de Tech Lead.

Nous n'avons pas encore de retour d'expérience à partager sur Joule. Cet article ne prétend donc pas en évaluer les capacités. Nos pratiques évolueront avec les outils, mais elles restent aujourd'hui fondées sur un principe : assister le développeur, pas lui retirer la responsabilité du développement.