Automatisation documentaire chez EDF

Dans le cadre de mon alternance chez EDF, sur un site de production nucléaire, j'ai conçu et développé une application interne visant à fiabiliser et automatiser toute une chaîne de gestion documentaire, de la demande émise par le métier jusqu'à sa prise en charge par le prestataire d'impression.

Le contexte et le problème

Un site de production nucléaire est soumis à de fortes exigences en matière de documentation technique : les agents doivent disposer de leurs documents de travail imprimés de façon fiable et dans les meilleurs délais.

Avant ce projet, les demandes d'impression étaient transmises au prestataire via des fichiers Excel non structurés. Ce fonctionnement générait deux problèmes concrets :

• des erreurs fréquentes dues à l'absence de contrôle sur la saisie (champs libres, formats non contraints) ;
• une perte de temps importante côté prestataire, qui devait réaliser les extractions de documents manuellement, une par une.

Objectif

Concevoir une application fiabilisant la saisie et automatisant l'ensemble de la chaîne, du métier jusqu'au prestataire. Contrainte imposée : rester dans le cadre de la politique Microsoft d'EDF, c'est-à-dire utiliser la suite Power Platform (Power Apps, Power Automate, SharePoint).

L'architecture : deux flux complémentaires

J'ai structuré la solution en deux flux distincts :

• Alimentation des données : un flux planifié maintient dans SharePoint une copie à jour du référentiel des documents imprimables, issu d'une base documentaire interne. La base n'étant pas directement accessible avec les licences disponibles, j'ai mis en place une synchronisation automatique (déclenchée par un e-mail planifié), traitée par un script pour produire un référentiel exploitable.
• Traitement des demandes : déclenché depuis l'interface, il prend en charge la saisie, la validation, la segmentation puis la transmission de la demande jusqu'au prestataire.

Plutôt que de tout concentrer dans un seul automate, j'ai découpé le traitement en plusieurs automates spécialisés se déclenchant en cascade. Ce choix s'inspire des bonnes pratiques du développement logiciel (éviter la duplication, faciliter la maintenance, faire évoluer un maillon sans tout casser) et améliore aussi nettement les performances.

L'interface et la validation à la saisie

L'interface Power Apps, destinée à des utilisateurs non-techniciens, propose deux modes de saisie adaptés aux pratiques du métier. J'ai implémenté toute une logique conditionnelle absente des composants natifs :

• validation croisée (deux modes de saisie qui ne peuvent pas être vides en même temps) ;
• listes déroulantes dépendantes (la seconde se filtre selon la première) ;
• champs conditionnels selon le type de demande.

Ce niveau de formalisation, chaque champ contrôlé, conditionné et validé avant transmission, élimine les erreurs de saisie à la source, ce qui était impossible avec les anciens fichiers Excel libres.

Contourner les limites du low-code (TypeScript)

Power Platform donne une impression de simplicité qui masque de vraies limites : pas d'expressions régulières, des performances insuffisantes sur les gros fichiers CSV, peu d'opérations de filtrage avancé. Pour les dépasser, j'ai développé des scripts TypeScript (Office Scripts) chargés de la conversion des fichiers, du nettoyage par regex et de la validation des données.

C'est l'un des enseignements clés du projet : savoir sortir ponctuellement du cadre no-code quand un besoin technique précis l'exige.

Défis techniques

• Optimisation des performances : mes premiers traitements en boucles For Each étaient inutilisables sur des volumes réels (plus d'une journée de traitement). Je les ai réécrits avec des actions Filter qui opèrent sur un tableau entier en une seule opération, bien plus rapides, mais nettement plus complexes à construire.
• Un bug de parsing subtil : certaines données contenaient des virgules, or la virgule servait de séparateur CSV, ce qui cassait silencieusement le traitement. Je l'ai résolu en changeant de caractère séparateur via un script.
• Débogage : sans breakpoints ni console, tracer une erreur dans un flux de plusieurs dizaines d'actions demande de la méthode et de la patience.
• Dépendances externes : une partie de la chaîne repose sur un système géré par une autre équipe. Toute évolution passe par des demandes formelles, une réalité fréquente en milieu industriel, où une partie des difficultés est organisationnelle plutôt que technique.

Le suivi des impressions

Dans un second temps, j'ai mis en place un suivi des impressions : une base dédiée (liste SharePoint) que j'ai conçue moi-même, qui suit chaque demande à travers trois états, en cours d'extraction, chez le prestataire d'impression, puis imprimée. Elle se met à jour automatiquement à chaque étape (réception de l'e-mail de traitement, puis validation des impressions par le prestataire via un tableau de bord Power BI). Objectif : redonner au métier la traçabilité de ses demandes de bout en bout.

Résultats & apprentissages

Les trois objectifs sont atteints : demandes structurées et validées à la saisie, suppression des extractions manuelles côté prestataire (qui reçoit directement les PDF prêts à imprimer), et chaîne entièrement automatisée. La structuration des demandes a même permis d'introduire de nouveaux traitements différenciés selon le type de document, jusqu'alors impossibles. Le déploiement est en cours, avec une vocation à être étendu à d'autres sites.

Au-delà de la technique, ce projet m'a appris à cadrer un besoin dans un environnement complexe et peu documenté, à faire des choix d'architecture assumés et à dialoguer avec toutes les parties prenantes (métier, prestataire, équipes internes). Il a aussi nuancé la promesse du low-code : entre les automates complexes et les scripts TypeScript, la solution requiert de réelles compétences de développement et n'est, en pratique, pas maintenable par un profil non technique, un point de vigilance que j'ai identifié pour sa pérennité.