Ouverture du marché de l'énergie sur SAP IS-U et CRM

À partir de juillet 2007, le marché résidentiel français de l'énergie s'est ouvert à la concurrence : Gaz de France pouvait vendre de l'électricité et EDF du gaz. GDF, avec 11 millions de clients en 2007, avait besoin d'un système d'information pour ses offres commerciales, ses contrats et sa facturation, y compris les nouvelles offres « Dual » (gaz et électricité). Le programme implémentait SAP CRM pour la gestion de la relation client, SAP IS-U pour la facturation et l'administration des ventes, et BW pour les indicateurs de pilotage. Plus de 200 consultants y sont intervenus, l'un des plus importants projets d'Accenture à cette époque. Arrivée en décembre 2006 comme programmeur ABAP dans une équipe de 20 développeurs, dont une partie en offshore à l'île Maurice, pour la version qui apportait tout le nécessaire à la vente d'électricité.

Le défi

Deux versions étaient déjà en production et couvraient la vente et la facturation du gaz. La version 3 devait apporter tout le nécessaire à la vente d'électricité, ainsi que de multiples améliorations et optimisations, et elle devait être prête pour l'ouverture du marché en juillet 2007. La pression était grande.

L'équipe de développement était scindée entre la maintenance de la production des versions en service et l'évolution (les nouvelles fonctionnalités). J'ai démarré ma carrière dans la partie évolution. Chaque développeur pouvait intervenir sur IS-U ou CRM ; j'ai travaillé sur les deux, avec un peu plus d'accent sur CRM. Le standard SAP ne répondait pas toujours aux nombreux besoins du client : le projet combinait donc beaucoup de configuration et de développements ABAP spécifiques.

Organisation du projet

Le projet suivait un cycle en V :

La réalisation se situait en bas du V. Les analystes, généralement des consultants plus expérimentés, traduisaient chaque besoin fonctionnel en spécification technique détaillée, et je transposais ces spécifications en algorithmes et programmes ABAP. Lors de la réunion d'équipe hebdomadaire, je rendais compte de mon avancement, partageais mes découvertes techniques, signalais tôt les points bloquants et m'engageais sur des dates de livraison.

• Tests unitaires : robustesse technique. Le programme se termine bien dans toute situation, gère les mauvaises données et affiche des messages d'erreur explicites. Je passais ensuite la main à l'analyste pour la revue de code.
• Tests d'intégration : les équipes de test déroulaient les cahiers de tests fonctionnels et saisissaient les anomalies dans l'outil de suivi. Je l'utilisais en permanence pour consulter les anomalies, corriger les programmes et commenter, et je travaillais directement avec les analystes fonctionnels, en démontrant parfois qu'une anomalie signalée était en fait un comportement correct.
• Recette (UAT) : les utilisateurs déroulaient des cahiers de tests selon leurs scénarios métier, et je reproduisais et corrigeais les nouvelles anomalies.

Les environnements de test contenaient de vrais contrats, adresses et numéros de téléphone. J'avais la responsabilité de ne jamais exploiter ces données ni de les laisser sortir des environnements du client.

Zoom technique : un modèle réutilisable d'interface entrante fichier vers IDoc

Le problème. Les IDoc sont conçus surtout pour les échanges entre systèmes SAP. Les fichiers plats, XML et web services étaient des alternatives, mais aucune ne disposait d'un suivi des intégrations inclus dans CRM et IS-U. Les programmes spécifiques de chargement de fichiers plats, par requêtes SQL ou appels de fonctions standard, doivent générer leurs propres logs, ce qui est fastidieux, peu uniforme et dispersé entre plusieurs outils. Le client voulait suivre chaque intégration : les classer et les rechercher, voir leur statut d'un coup d'œil, obtenir des messages d'erreur explicites et rejouer les échecs.

La solution. J'ai utilisé les IDoc SAP même pour les flux entrants non-SAP vers SAP, ce qui évitait de lourds développements spécifiques. Les fichiers arrivaient dans un espace FTP côté SAP. Du code ABAP spécifique les lisait avec les commandes de fichiers et chargeait les données dans les structures IDoc, qui servaient de table tampon.

L'exemple que j'ai développé était l'interface de modification des contrats électricité dans CRM. Un système amont déposait dans un répertoire dédié du serveur des fichiers XML contenant des mises à jour de contrats, comme les résiliations, et des données de relevés de compteurs. Le standard SAP peut intégrer les IDoc de contrats et de compteurs sans développement, en appelant les modules de fonction standard liés à ces types d'IDoc. Des champs et tables spécifiques devaient aussi être mis à jour, ce que j'ai fait avec des user exits dans le code standard.

Étapes du traitement :

1. Lire le fichier et effectuer un contrôle d'intégrité.
2. En cas d'erreur, écrire le log et le message d'erreur, puis terminer. Sinon, continuer.
3. Mapper les lignes du fichier sur les segments IDoc.
4. Créer les IDoc.
5. Intégrer les IDoc, ce qui met à jour les données des contrats et les compteurs.
6. Les IDoc dont l'intégration échoue sont mis au statut erreur et alimentent une table fonctionnelle des rejets.
7. Produire le compte rendu d'exécution et terminer.

Les logs et les mises à jour de la base sont écrits au fil du traitement.

Pourquoi cela a fonctionné. Les IDoc ainsi créés bénéficient du suivi intégré de SAP sans développement supplémentaire : intégrations par jour, statut et retraitement des erreurs. La maintenance de production est devenue beaucoup plus simple, et les utilisateurs pouvaient vérifier la bonne réception de leurs fichiers dans SAP et voir ce qui n'avait pas fonctionné. Les autres interfaces entrantes du projet ont suivi la même architecture, ce qui a permis une gestion uniforme et fiable des messages entrants.

Zoom technique : la performance à 11 millions de clients

Contraintes. Le client imposait des standards de performance pour chaque extraction spécifique :

• Les traitements de la nuit applicative devaient se terminer avant le début de la journée du métier, et avant les batchs qui en dépendaient.
• Les documents devaient se sauvegarder dans un temps acceptable.
• Les recherches de clients et de factures devaient être rapides. Les agents de la hotline qui répondaient aux appels clients avaient besoin des données client et contrat presque instantanément.
• Les rapports portant sur tous les clients et toutes les factures devaient se terminer à temps.
• Les tables pouvaient atteindre des dizaines voire des centaines de millions d'enregistrements, révélant des lenteurs qui n'apparaissaient pas en test.

Démarche.

1. Les anomalies de performance issues des tests d'intégration et de la recette m'étaient assignées.
2. Je les reproduisais dans un environnement dédié à la performance contenant des millions d'enregistrements, copiés depuis la production quand c'était possible ou transformés pour masquer les données sensibles comme les coordonnées bancaires.
3. Je mesurais avec la trace d'analyse d'exécution de SAP, qui enregistre chaque instruction et sa durée, puis je corrigeais le code et le livrais de nouveau pour un nouveau test, en vérifiant à la fois l'exactitude et la rapidité.

Le paysage reposait sur l'architecture R/3 classique en trois tiers : SAP GUI, plusieurs serveurs d'applications ABAP se partageant la charge et une base de données Oracle. Les goulots d'étranglement pouvaient se situer dans n'importe quel tiers.

Corrections du code :

• Lire les tables internes par recherche dichotomique plutôt que par lecture séquentielle. La recherche dichotomique ne fonctionne que sur la clé de tri : je copiais et triais donc souvent la table au préalable.
• Supprimer les boucles imbriquées, en sortant le traitement de la boucle principale au profit de simples lectures de tables, et parfois revoir l'algorithme.
• Sortir des boucles les opérations coûteuses comme les SORT.
• Supprimer les traitements inutiles, ne récupérer que les données pertinentes et sortir au plus tôt.

Corrections SQL :

• Utiliser la trace SQL pour voir l'ordre des jointures et l'utilisation des index, et ajouter des critères de sélection pour qu'un index existant soit utilisé.
• Considérer un nouvel index comme un dernier recours. Un index est une copie physique triée : il prend de la place, ralentit les insertions et mises à jour, et peut dégrader les performances générales.
• Limiter le nombre de requêtes et lire en masse, puis traiter dans la mémoire du serveur d'applications. Le disque est environ mille fois plus lent que la mémoire vive, et les serveurs d'applications travaillent en parallèle.
• Utiliser la mise en buffer des tables uniquement pour les tables de paramétrage qui ne changent pas.
• Transmettre les problèmes de matériel et de configuration à l'équipe Basis avec mon analyse et ma recommandation. Le travail sur la base de données s'appuyait aussi sur des connaissances Oracle en index, statistiques et hints.

Ce que j'en ai retenu

• La rigueur paie. Réduire le nombre d'anomalies en tests d'intégration était le principal critère sur lequel mes responsables m'évaluaient.
• Le respect strict des normes de développement et des règles de nommage, ainsi que la revue du code de mes collègues, m'ont donné des habitudes ABAP disciplinées. Ces habitudes m'ont ensuite permis de former de nouveaux développeurs.
• J'ai réutilisé le modèle fichier vers IDoc dans des projets ultérieurs chez Allianz, Total et L'Oréal.
• La performance représente une grande part de la satisfaction client, et elle se gagne surtout dans l'algorithme et le SQL, pas dans le matériel.