GRDF : un moteur de règles GTA refondu sans aucune régression

ÉTUDE DE CAS · ÉNERGIE & SERVICE PUBLIC

483 règles, 53 flux SAP, 12 000 salariés, et pas de place pour une seule erreur.

Refondre le moteur de règles de la gestion des temps et activités, sur un système où la moindre erreur atterrit directement sur une fiche de paie.

Client

GRDF

Expertise

Moteur de règles · Delivery piloté par la spec · Non-régression

Stack technique

ASDD · Tests générés · Intégration SAP

CONTEXTE

Contexte du projet

GRDF opère le réseau de distribution de gaz français. Son système de gestion des temps et activités, la GTA, régit les horaires, les plannings et la paie de 12 000 salariés.

Le moteur qui le fait tourner devait être refondu : des centaines de règles métier à réimplémenter, et des dizaines de flux SAP à reconnecter et à fiabiliser. Le tout sans jamais interrompre la paie ni les plannings.

Sur ce type de système, une régression n'est pas un défaut consigné dans un backlog. C'est une vacation mal affectée, ou un salaire versé incomplet. L'exigence n'était donc pas un taux d'erreur faible, mais aucune erreur.

Objectifs stratégiques

OBJECTIFS

(01)

Des règles qui portent tout le métier

483 règles de gestion des temps à réimplémenter, chacune encodant un accord, une exception ou une contrainte légale accumulée au fil des années.

(02)

Un périmètre qu'on ne peut pas interrompre

12 000 salariés dont la paie et les plannings dépendent du système. La refonte devait se faire sans aucune interruption de service.

(03)

Des flux à reconnecter un par un

53 flux SAP à intégrer et à fiabiliser. Chacun porte des données que d'autres systèmes consomment en aval, donc une erreur se propage au lieu de rester locale.

(04)

Zéro régression, pas « peu »

La barre d'acceptation était absolue. Prouver l'absence de régression sur 483 règles demande une couverture qu'aucune campagne de tests manuels ne produit dans un délai raisonnable.

Solutions déployées par Adservio

SOLUTIONS

Une démarche pilotée par la spec : chaque règle est spécifiée de façon exécutable, puis générée et testée sous revue d'ingénieur. Les agents de delivery portent le volume, les ingénieurs portent la décision, et l'intégration SAP est validée flux par flux avant d'atteindre la production.

(01)

Chaque règle spécifiée de façon exécutable

Chacune des 483 règles devient une spécification exécutable plutôt qu'un paragraphe dans un document. C'est de cette spécification que découlent à la fois l'implémentation et les tests.

(02)

Une implémentation générée sous revue

Les agents de delivery produisent l'implémentation de chaque règle, et un ingénieur la revoit avant intégration. Le volume est absorbé par les agents, le jugement reste humain.

(03)

Une couverture de non-régression produite avec les règles

Les agents génèrent aussi la couverture de non-régression. Prouver que 483 règles se comportent comme avant n'est faisable que si les tests sont produits au même rythme que le code.

(04)

Une intégration SAP validée flux par flux

Les 53 flux sont intégrés et validés un par un avant mise en production, plutôt qu'en un seul lot. Un écart est attrapé sur son propre flux, pas une fois que tout est raccordé.

Résultats

CHIFFRES CLÉS

483

Règles réimplémentées

L'ensemble des règles de gestion des temps refondu, chacune spécifiée, générée et testée sous revue d'ingénieur.

Flux SAP intégrés

Chaque flux reconnecté et validé isolément avant la mise en production.

12 000

Salariés couverts

Le périmètre du système : les horaires, les plannings et la paie de 12 000 salariés de GRDF.

Impact

CE QUE ÇA CHANGE

Une refonte restée invisible

La paie et les plannings ne se sont jamais arrêtés. Sur un système critique, la mesure du succès, c'est que personne en dehors du projet n'ait remarqué que le moteur avait changé en dessous.

Une couverture qu'on montre, pas qu'on affirme

La non-régression générée en même temps que les règles transforme une affirmation en preuve. L'absence de régression est démontrée sur les 483 règles, pas sur un échantillon.

Des règles redevenues lisibles

Les spécifications exécutables laissent derrière elles un corpus de règles qu'on peut lire, tester et modifier. Ce qui était enfoui dans un moteur hérité devient un actif documenté.