Product Engineering Retrospective — UNIM Membres

Comment automatiser un processus métier reposant sur des données non structurées pour réduire les opérations manuelles et fiabiliser l’intégration dans Drupal

1. Contexte du projet

Le projet UNIM Membres s’inscrit dans un contexte classique mais sensible : une organisation dispose d’un volume important de données membres, mais ces données ne sont pas centralisées dans un système fiable dès le départ.

L’Union Nationale des Ingénieurs Marocains avait besoin de structurer progressivement une plateforme de gestion des membres, des adhésions et des informations associées. Le sujet n’était donc pas uniquement de créer une interface Drupal, mais de construire un référentiel exploitable à partir de données existantes, souvent dispersées et parfois imparfaites.

Le processus concernait principalement les personnes chargées de la gestion administrative des membres, de l’intégration des demandes, du suivi des informations et de la consolidation des données. Ces utilisateurs avaient besoin d’un système plus fiable, moins dépendant des manipulations manuelles.

Le problème central était le suivant : les données membres arrivaient sous différentes formes, avec des niveaux de qualité variables, et nécessitaient un important travail de reprise avant intégration.

Le processus existant devenait problématique parce qu’il reposait sur des opérations répétitives : lecture d’emails, extraction d’informations, nettoyage de fichiers, vérification manuelle, correction de champs, préparation à l’import, puis intégration dans Drupal.

Chaque manipulation humaine ajoutait un risque : erreur de saisie, oubli d’un membre, doublon, mauvaise correspondance de secteur, champ vide, format incohérent ou information mal interprétée.

L’impact n’était pas seulement technique. Il touchait directement la qualité du référentiel membres. Un système de membres fiable dépend d’abord de la qualité des données qui l’alimentent. Si l’entrée est fragile, tout le reste devient fragile : recherche, filtres, statistiques, suivi des adhésions, communication, historique et évolutions futures.

2. Situation de départ

Les données arrivaient depuis plusieurs sources. Certaines provenaient de fichiers structurés, d’autres de fichiers semi-structurés, et une partie importante était contenue dans des échanges email. Cela impliquait que les informations utiles n’étaient pas toujours disponibles dans un format directement exploitable.

Les données pouvaient contenir des informations comme l’identité du membre, ses coordonnées, son secteur, son statut, son origine organisationnelle, ou encore des informations liées à son adhésion. Mais ces données n’étaient pas toujours présentes au même endroit, ni avec la même nomenclature.

Les formes reçues pouvaient inclure :

• fichiers tabulaires ;
• exports partiels ;
• listes transmises manuellement ;
• contenus d’emails ;
• pièces jointes ;
• informations textuelles non normalisées ;
• données nécessitant une interprétation avant import.

Le traitement manuel consistait souvent à récupérer les données, les relire, les copier, les reformater, corriger certains champs, compléter des informations manquantes, puis préparer l’import dans Drupal.

Les erreurs régulières étaient typiques des processus de reprise de données :

• doublons ;
• noms saisis différemment ;
• emails absents ou mal formatés ;
• champs obligatoires incomplets ;
• secteurs non normalisés ;
• valeurs proches mais non identiques ;
• erreurs de correspondance entre colonnes ;
• données placées dans le mauvais champ ;
• informations exploitables mais enfouies dans du texte libre.

Les limites du processus étaient claires : il ne passait pas à l’échelle. Plus le volume augmentait, plus le coût humain augmentait. Plus les sources se multipliaient, plus le risque d’incohérence devenait important. Le processus manuel pouvait fonctionner ponctuellement, mais il n’était pas adapté à une plateforme durable.

3. Contraintes métier

La première contrainte était la qualité des données. Dans un référentiel membres, une donnée incorrecte peut avoir un effet domino : un membre peut être mal classé, un email peut ne pas être envoyé, une statistique peut être faussée, une demande peut être mal suivie.

La deuxième contrainte était organisationnelle. L’UNIM n’avait pas simplement besoin d’un import ponctuel. Il fallait penser un processus réutilisable, compréhensible et maintenable, capable d’accompagner les évolutions futures de la plateforme.

Les données membres imposaient aussi des contraintes spécifiques. Un membre n’est pas une simple ligne dans un fichier. Il peut être associé à un statut, un secteur, une région, une demande, un historique ou des informations administratives. Le modèle devait donc éviter une intégration trop plate ou trop figée.

La traçabilité était également importante. Il fallait pouvoir comprendre ce qui avait été importé, ce qui avait été ignoré, ce qui avait été corrigé, et ce qui nécessitait une revue humaine. Sans traçabilité, l’automatisation devient dangereuse : elle accélère les erreurs au lieu de les réduire.

Les mises à jour représentaient une autre contrainte. Le système devait éviter de recréer systématiquement les mêmes entrées ou de produire des doublons. Il fallait donc réfléchir à des mécanismes de correspondance, de détection et de contrôle.

La fiabilité des imports était essentielle. Un import ne devait pas uniquement “passer techniquement”. Il devait produire un résultat métier correct. Cela implique des validations avant intégration, des contrôles après traitement et une capacité à isoler les cas problématiques.

Enfin, il existait une contrainte de temps. Le processus devait réduire la charge manuelle, pas créer une usine à gaz. L’enjeu était donc de construire une solution robuste mais pragmatique.

4. Contraintes techniques

Drupal était le système cible. Cela imposait de respecter son modèle de contenu, ses entités, ses champs, ses taxonomies, ses contraintes de validation et ses mécanismes de configuration.

L’intégration ne pouvait pas être pensée comme une simple insertion brute en base de données. Dans Drupal, contourner les APIs peut produire des effets secondaires : champs mal indexés, révisions incohérentes, traductions mal gérées, cache non invalidé, hooks non exécutés. Il fallait donc garder Drupal comme couche d’intégration contrôlée.

Les sources de données étaient hétérogènes. Certaines étaient structurées, d’autres semi-structurées, d’autres issues d’emails. Cette hétérogénéité rendait difficile une approche unique. Un import CSV classique ne suffisait pas si les données devaient être extraites, nettoyées et interprétées avant l’import.

Les emails représentaient une contrainte particulière. Un email n’est pas un format de données stable. La structure peut varier, les informations peuvent être dans le corps du message, dans une pièce jointe, dans une formulation libre ou dans une mise en forme peu fiable. Il fallait donc traiter l’email comme une source d’extraction, pas comme une donnée prête à intégrer.

Les formats de fichiers posaient aussi problème. Colonnes variables, encodage, intitulés différents, valeurs non normalisées, données manquantes : tout cela imposait une étape de transformation avant Drupal.

La maintenance était une contrainte majeure. Une automatisation utile aujourd’hui mais impossible à comprendre demain devient une dette technique. Il fallait donc séparer les responsabilités : extraction et transformation d’un côté, intégration Drupal de l’autre.

L’automatisation devait rester contrôlable. Le but n’était pas de tout automatiser aveuglément, mais d’automatiser ce qui pouvait l’être avec un bon niveau de confiance, et de signaler les cas nécessitant une revue humaine.

La validation des données devait donc être intégrée au pipeline, pas ajoutée après coup. Elle devait permettre de distinguer les données importables, les données à corriger et les données à ignorer.

Enfin, l’évolution future devait être anticipée. Le système devait pouvoir accueillir de nouvelles sources, de nouveaux champs, de nouveaux statuts et de nouvelles règles métier sans devoir être entièrement réécrit.

5. Les options étudiées

Option 1 — Continuer le traitement manuel

L’avantage principal était la simplicité immédiate. Aucun développement supplémentaire n’était nécessaire. Les gestionnaires pouvaient continuer à travailler avec les fichiers et emails existants.

Mais cette option ne résolvait rien structurellement. Elle maintenait les erreurs humaines, la charge répétitive et l’absence de traçabilité fiable. Elle rendait aussi la plateforme dépendante d’un savoir implicite détenu par quelques personnes.

Cette option a été rejetée parce qu’elle ne permettait pas de construire un système durable.

Option 2 — Import CSV classique dans Drupal

L’import CSV était une option naturelle. Drupal peut intégrer des données structurées via des outils d’import ou des développements spécifiques.

L’avantage était la proximité avec Drupal et la relative simplicité de mise en œuvre pour des données propres.

Mais cette approche supposait que les données soient déjà normalisées. Or le vrai problème se situait avant l’import : extraction, nettoyage, mapping, détection des incohérences, préparation des valeurs.

Un CSV classique aurait déplacé le problème sans le résoudre. Il aurait fallu nettoyer manuellement les fichiers avant chaque import.

Cette option a été écartée comme solution unique, mais l’idée de fichier intermédiaire normalisé restait utile comme étape possible dans le pipeline.

Option 3 — Développement Drupal uniquement

Une autre option consistait à tout faire dans Drupal : extraction, transformation, validation et intégration.

L’avantage était de centraliser la logique dans un seul environnement applicatif. Drupal aurait pu gérer les formulaires, les entités, les validations et les imports.

Mais Drupal n’est pas l’outil le plus efficace pour manipuler des fichiers hétérogènes, extraire des données depuis du texte ou réaliser des traitements de masse exploratoires. Développer toute la logique de parsing et de transformation dans Drupal aurait alourdi le système.

Cette option risquait aussi de mélanger deux responsabilités : le traitement de données amont et la gestion applicative métier.

Elle a donc été rejetée comme approche exclusive.

Option 4 — Scripts Python uniquement

Python était très adapté à l’extraction, au nettoyage et à la transformation des données. Il permettait de manipuler facilement fichiers, chaînes de caractères, formats tabulaires et règles de normalisation.

L’avantage était la rapidité de développement et la flexibilité pour traiter des données imparfaites.

Mais Python seul ne pouvait pas remplacer Drupal comme système métier. Il ne devait pas devenir le référentiel principal ni contourner les règles applicatives. Une intégration directe en base aurait été risquée.

Cette option a donc été retenue uniquement pour la partie extraction et transformation, mais rejetée comme solution complète.

Option 5 — Solution hybride Python + Drupal

La solution hybride consistait à utiliser Python pour ce qu’il fait bien : extraire, nettoyer, transformer, préparer. Puis utiliser Drupal pour ce qu’il fait bien : structurer, valider, stocker, exposer et gérer les données métier.

Cette approche permettait de séparer clairement le pipeline de préparation des données et le système cible.

Les avantages étaient importants :

• meilleure maintenabilité ;
• meilleure séparation des responsabilités ;
• automatisation plus souple ;
• intégration Drupal contrôlée ;
• possibilité d’ajouter des validations métier ;
• capacité à traiter des données non structurées avant import.

L’inconvénient était une architecture plus riche, avec deux environnements à maintenir. Mais ce coût était acceptable car il correspondait à la réalité du problème.

Cette option a été adoptée.

Option 6 — Outils no-code ou ETL externe

Une approche avec un outil ETL ou no-code aurait pu être envisagée pour automatiser certains flux.

L’avantage aurait été une mise en place rapide pour des transformations simples.

Mais le besoin comportait des règles métier spécifiques, une intégration Drupal personnalisée et des cas particuliers liés aux données membres. Un outil générique aurait rapidement atteint ses limites ou créé une dépendance externe peu maîtrisée.

Cette option n’a pas été retenue pour le cœur du système.

6. Arbitrages réalisés

Python a été utilisé parce que le problème principal était un problème de traitement de données avant intégration. Il fallait extraire des informations, nettoyer des champs, normaliser des valeurs, identifier des anomalies et produire une donnée exploitable.

Drupal a été conservé comme système cible parce qu’il représentait la plateforme métier. Les membres devaient être gérés dans un système structuré, extensible, administrable et compatible avec les futurs besoins de l’UNIM.

Certains traitements ont été externalisés hors Drupal pour éviter de transformer Drupal en outil de parsing. Ce choix évite d’alourdir les modules Drupal avec une logique de nettoyage trop spécifique aux sources.

Les validations ont été mises en place pour éviter que l’automatisation ne devienne un accélérateur d’erreurs. Une automatisation sans contrôle est dangereuse : elle permet d’importer plus vite, mais aussi de dégrader plus vite la qualité du référentiel.

Certaines automatisations ont été retenues lorsqu’elles reposaient sur des règles suffisamment fiables : normalisation de champs, extraction depuis des structures connues, mapping de certaines valeurs, préparation des données.

D’autres automatisations ont été reportées lorsqu’elles nécessitaient une interprétation humaine ou lorsque le risque de mauvaise décision automatique était trop élevé. Dans ces cas, le système devait plutôt signaler les données à revoir.

Le raisonnement général était pragmatique : automatiser les tâches répétitives et déterministes, conserver une validation humaine sur les cas ambigus.

7. Architecture mise en place

L’architecture repose sur un pipeline de traitement en plusieurs étapes.

Étape 1 — Collecte des sources

Les données sont récupérées depuis les fichiers disponibles et les contenus issus des échanges email. Cette étape consiste à identifier les sources exploitables et à les transformer en entrées de traitement.

Étape 2 — Extraction

Les scripts Python extraient les informations pertinentes. Selon la source, l’extraction peut porter sur des colonnes de fichiers, du texte semi-structuré ou des informations récupérées depuis des contenus email.

L’objectif n’est pas encore d’importer dans Drupal, mais de produire une représentation exploitable de la donnée.

Étape 3 — Transformation

Les données extraites sont transformées pour correspondre au modèle attendu par Drupal.

Cette transformation peut inclure :

• nettoyage des espaces ;
• harmonisation des formats ;
• normalisation des libellés ;
• standardisation des emails ;
• préparation des valeurs de taxonomie ;
• conversion de certains champs ;
• structuration des données membres.

Étape 4 — Nettoyage

Les valeurs incohérentes sont corrigées lorsque la règle est évidente. Les cas ambigus sont isolés.

Cette étape permet d’éviter d’envoyer à Drupal des données trop brutes. Drupal ne doit pas recevoir une donnée qui nécessite encore une forte interprétation.

Étape 5 — Validation

Les données sont contrôlées avant import.

Les validations peuvent porter sur :

• présence des champs nécessaires ;
• format des emails ;
• cohérence des valeurs ;
• correspondance avec les vocabulaires Drupal ;
• détection de doublons ;
• identification des lignes incomplètes ;
• repérage des cas nécessitant une revue.

Étape 6 — Préparation à l’intégration

Le pipeline produit une donnée normalisée, prête à être intégrée dans Drupal. À ce stade, la donnée doit être suffisamment propre pour limiter les erreurs applicatives.

Étape 7 — Intégration Drupal

Les modules Drupal personnalisés prennent le relais pour intégrer les données dans le modèle applicatif.

Drupal devient la couche de persistance métier. Les données membres sont intégrées selon la structure prévue : entités, champs, taxonomies, statuts, règles métier et éventuels mécanismes de suivi.

Étape 8 — Contrôle qualité après import

Après intégration, des contrôles permettent de vérifier le résultat : nombre d’éléments traités, éléments ignorés, erreurs, doublons potentiels, données à revoir.

Le système ne doit pas seulement dire “import terminé”. Il doit permettre de comprendre ce qui a été réellement intégré.

Gestion des erreurs

Les erreurs sont traitées comme des informations métier. Une ligne rejetée n’est pas seulement une erreur technique ; c’est souvent le signe d’une donnée source incomplète ou ambiguë.

L’objectif est donc de classer les erreurs :

• erreurs bloquantes ;
• erreurs corrigibles ;
• données à revoir ;
• doublons probables ;
• valeurs sans correspondance.

Gestion des doublons

La gestion des doublons est centrale. Elle peut s’appuyer sur des clés comme l’email, des combinaisons nom/prénom, ou d’autres informations disponibles.

Le choix important est de ne pas considérer automatiquement toutes les ressemblances comme des doublons certains. Certains cas doivent être marqués pour revue plutôt que fusionnés automatiquement.

8. Difficultés rencontrées

Qualité des données

La difficulté principale venait de la qualité hétérogène des données. Les informations n’étaient pas toujours complètes, correctement formatées ou cohérentes.

Cette difficulté apparaît souvent quand une organisation accumule des données sur plusieurs années sans référentiel unique. Les fichiers deviennent des instantanés partiels, les emails deviennent des sources informelles, et les conventions changent avec le temps.

Le traitement a consisté à normaliser ce qui pouvait l’être et à isoler les cas incertains.

Avec le recul, une phase initiale de profiling statistique des données aurait pu être encore plus poussée : taux de champs vides, distribution des valeurs, fréquence des doublons, qualité par source.

Formats hétérogènes

Les données ne suivaient pas toujours le même format. Cela empêchait de construire un import unique et direct.

La solution a été de séparer l’extraction de la transformation. Chaque source peut nécessiter une logique spécifique, mais la sortie du pipeline doit converger vers un format commun.

Ce qui aurait pu être renforcé : documenter explicitement chaque format source et son mapping vers Drupal.

Extraction depuis les emails

Les emails posent un problème particulier parce qu’ils sont conçus pour la communication humaine, pas pour l’intégration applicative.

L’extraction peut devenir fragile si la structure des messages change. Le traitement a donc dû rester prudent : automatiser les cas identifiables, éviter les hypothèses trop agressives, et prévoir des cas de rejet.

Avec le recul, il aurait été préférable de réduire progressivement la dépendance aux emails en imposant des formulaires ou fichiers sources mieux structurés.

Validation

La validation n’était pas uniquement technique. Il fallait distinguer une donnée techniquement valide d’une donnée métier fiable.

Un email peut être syntaxiquement valide mais appartenir à la mauvaise personne. Un secteur peut être renseigné mais ne pas correspondre à la nomenclature attendue. Un nom peut être présent mais écrit de plusieurs façons.

La validation a donc dû combiner règles techniques et règles métier.

Synchronisation avec Drupal

Drupal impose son propre modèle. Il fallait éviter une intégration trop brute qui aurait court-circuité les mécanismes internes.

La synchronisation devait respecter les entités, les champs, les taxonomies et les contraintes applicatives.

Le traitement a consisté à faire de Drupal la source applicative finale, mais pas l’outil principal de nettoyage amont.

Cas particuliers

Comme dans tout projet de reprise de données, les cas particuliers ont représenté une part importante du travail.

Ils apparaissent quand une donnée ne correspond pas aux règles prévues : membre sans email, secteur absent, valeur inconnue, doublon probable, information contradictoire.

La décision importante a été de ne pas chercher à tout résoudre automatiquement. Certains cas doivent être sortis du flux principal et traités séparément.

Maintenance

La maintenance d’un pipeline hybride peut devenir complexe si les responsabilités ne sont pas claires.

Le risque était de disperser la logique métier entre Python et Drupal. Pour limiter ce risque, il fallait définir une frontière : Python prépare et normalise ; Drupal intègre et applique le modèle métier.

Avec le recul, cette frontière mérite d’être documentée dès le départ dans un schéma d’architecture et une convention de responsabilité.

9. Résultats obtenus

Le premier résultat observable est la réduction des opérations manuelles. Les tâches répétitives de nettoyage, préparation et transformation peuvent être automatisées ou semi-automatisées.

Le deuxième résultat est l’amélioration de la fiabilité. Les données passent par des contrôles avant intégration, ce qui limite les erreurs introduites dans Drupal.

Le troisième résultat est le gain de temps. Le temps humain est déplacé : moins de copier-coller et de reformattage, plus de revue ciblée sur les cas ambigus.

Le quatrième résultat est l’amélioration de la qualité du référentiel membres. Les champs sont plus cohérents, les formats plus homogènes et les erreurs plus visibles.

Le cinquième résultat est la simplification du processus. Même si l’architecture technique est plus avancée, le processus métier devient plus clair : collecter, extraire, transformer, valider, intégrer, contrôler.

Le sixième résultat est la maintenabilité. En séparant les scripts de traitement de données et les modules Drupal, le système peut évoluer plus facilement.

10. Ce qui serait fait différemment aujourd’hui

La décision de conserver une architecture hybride Python + Drupal reste pertinente. Elle correspond bien à la nature du problème.

La décision de ne pas tout automatiser aveuglément reste également valide. Sur des données membres, certains choix nécessitent une validation humaine.

Ce qui pourrait être amélioré aujourd’hui :

• ajouter une phase plus formelle de data profiling avant traitement ;
• produire des rapports d’import plus détaillés ;
• ajouter une interface de revue des anomalies dans Drupal ;
• mieux historiser les imports ;
• versionner les règles de transformation ;
• documenter chaque mapping source vers modèle Drupal ;
• prévoir des tests automatisés sur des jeux de données représentatifs ;
• créer un tableau de bord qualité des données.

Une évolution possible serait de construire un véritable back-office d’import dans Drupal, où les gestionnaires pourraient voir les données prêtes à intégrer, les anomalies, les doublons probables et les lignes rejetées.

Une autre amélioration serait de réduire progressivement les sources non structurées. L’automatisation est utile, mais le meilleur pipeline reste celui qui reçoit de meilleures données en entrée.

11. Enseignements Product Engineering

Le premier enseignement est qu’un processus métier manuel ne doit pas être automatisé tel quel. Il faut d’abord comprendre ce qu’il fait réellement, où sont les décisions humaines, où sont les règles implicites, et où apparaissent les erreurs.

Le deuxième enseignement est qu’un pipeline de données doit être conçu comme un produit interne. Il a des utilisateurs, des contraintes, des erreurs, des retours et un cycle de vie.

Le troisième enseignement est que Python et Drupal sont complémentaires. Python est efficace pour manipuler des données imparfaites, faire de l’extraction, de la transformation et du nettoyage. Drupal est plus pertinent comme système métier structuré, avec ses entités, ses champs, ses règles et son back-office.

Le quatrième enseignement est que la qualité des données ne se corrige pas uniquement dans le code. Elle se travaille à plusieurs niveaux : source, format, validation, mapping, contrôle, documentation et revue humaine.

Le cinquième enseignement est que la maintenabilité dépend de la séparation des responsabilités. Si toute la logique est dans Drupal, le système devient lourd. Si toute la logique est dans Python, Drupal devient une simple base cible. La bonne architecture consiste à placer chaque responsabilité au bon endroit.

Le sixième enseignement est que l’automatisation doit être progressive. Il faut automatiser d’abord les tâches répétitives, déterministes et peu risquées. Ensuite seulement, on peut traiter les cas plus complexes.

Le septième enseignement est qu’un système fiable ne cherche pas à cacher les anomalies. Il les rend visibles. Une bonne automatisation ne supprime pas tous les problèmes ; elle les classe, les isole et permet de les traiter plus efficacement.

Le dernier enseignement est que la création de valeur ne vient pas uniquement du développement d’une plateforme. Elle vient de la transformation d’un processus fragile en système contrôlé, répétable, traçable et évolutif.

Dans UNIM Membres, le sujet technique apparent était l’import de données dans Drupal. Le vrai sujet Product Engineering était plus large : concevoir un système capable de transformer un flux de données désordonné en référentiel métier fiable.