Architecture de solutions

Architecture de solutions : ERP, intégration et données.

Analyste d'affaires TI senior (9+ ans en TI) à forte profondeur technique. Cet espace présente les projets où j'ai spécifié, intégré ou conçu des solutions ERP, d'intégration et de données, mon rôle exact et les résultats vérifiés. Chaque dossier précise ce qui relève de la conception, de la spécification ou de l'intégration.

Chaque dossier suit la même structure : contexte, état initial, conception et contraintes documentées, réalisation, résultats. Les alternatives écartées ne sont pas reconstruites lorsqu'elles ne sont pas documentées, et les schémas sont des représentations simplifiées reconstruites à partir des éléments publiés — jamais des documents originaux ni des schémas internes de clients.

CV Architecture de solutions (PDF)CV Analyste d'affaires TI (PDF)Discuter d'un poste ou mandat

Cinq façons de créer de la valeur

  • Comprendre des processus métier complexes

    50+ récits utilisateur et critères d'acceptation, processus actuels et cibles.

  • Spécifier et concevoir des solutions adaptées

    Pipelines de données vers un entrepôt SQL Server, modules ERP/MRP spécifiés, produit de migration.

  • Faire communiquer ERP, applications et données

    Flux WMS par API REST, flux ETL, migration entre SGBD.

  • Relier besoins d'affaires, contraintes techniques et impacts

    Traçabilité, analyses d'impacts et recette avec les propriétaires métier.

  • Accompagner jusqu'aux tests et à la production

    Essais d'acceptation, mise en production, formation de 30 utilisateurs.

Types d'architecture réellement pratiqués

  • Pipelines de données et reporting

    Pipelines SQL/Python/ETL consolidant 8+ sources vers un entrepôt SQL Server, avec contrôles qualité automatisés.

    Dossier Coallia

  • Intégration applicative par API REST

    Flux WMS reliés à 3 transporteurs et 2 canaux e-commerce sur 3 sites.

    Dossier BK Systèmes

  • Applications ERP/MRP

    4 modules (production, stock, commandes, facturation) et flux ETL, jusqu'à la mise en production.

    Dossier Chez André

  • Interopérabilité et migration de données

    Logiciel de migration HFSQL vers PostgreSQL, MySQL, MariaDB et SQL Server : moteur ETL, synchronisation miroir, bascule, destination logique explicite.

    Dossier UniDataTransfer

  • Plateforme d'orchestration d'agents IA

    Système local de gouvernance de la livraison logicielle : méthode commune, gates, mémoire, décisions consignées dans des ADR.

    Dossier UDE

Dossiers d'architecture

Coallia

5 jours → 2 jours

Architecture de données, systèmes d'affaires et intégration ERP

Rôle personnel exercé

  • Consultant principal, BTBSofting : conception des pipelines SQL/Python/ETL alimentant l'entrepôt de données, exigences et essais d'acceptation du reporting, pilotage du volet ERP, intégration et données du mandat.

Flux de données du reporting Coallia (représentation simplifiée)

  1. Sources

    • 8+ sourcesdonnées opérationnelles

  2. Traitement

    • Pipelines SQL/Python/ETL30 indicateurs · 17 contrôles

  3. Stockage

    • Entrepôt SQL Server

  4. Consommation

    • Reportinglivraison BI
    • Propriétaires métieressais d'acceptation
Plus de 8 sources alimentent des pipelines SQL, Python et ETL (mappages, 30 indicateurs, 17 contrôles qualité automatisés). Les données sont consolidées dans un entrepôt SQL Server, puis exposées dans le reporting, validé avec les propriétaires métier.

01Contexte et problème

  • Organisation de 4 500+ employés et 200+ établissements.
  • Cinq jours pour produire les rapports mensuels, des sources dispersées et des définitions d'indicateurs peu partagées entre affaires et TI.

02État initial

  • 8+ sources de données à consolider.
  • Cycle de production des rapports de 5 jours.

03Conception et contraintes documentées

  • Solution mise en œuvre : un entrepôt SQL Server alimenté par des pipelines SQL/Python/ETL qui consolident les 8+ sources.
  • Mappages, 30 indicateurs et 17 contrôles qualité automatisés ; essais d'acceptation menés avec les propriétaires métier.
  • Contrainte documentée : définitions d'indicateurs à partager entre affaires et TI.

04Réalisation

  • Environnement : SQL avancé, Python, ETL, SQL Server, UAT.
  • Validation : 17 contrôles qualité automatisés et essais d'acceptation du reporting.

05Résultats vérifiés

  • Cycle de production réduit de 60 % (5 → 2 jours) et anomalies en validation réduites de 40 %.
  • Vélocité accrue de 15 %.

Limites du périmètre

  • Périmètre : reporting et volet ERP, intégration et données du mandat ; l'architecture d'entreprise du client n'est pas revendiquée.
  • Schéma : représentation simplifiée reconstruite à partir des éléments publiés (l'ordre et le sens des flux sont une lecture simplifiée) ; aucun document original ni schéma interne du client n'est publié.
Voir l'étude de cas

Chez André

+65 % productivité

Applications ERP/MRP retail : modules et flux de données

Rôle personnel exercé

  • Analyste d'affaires TI : spécifications fonctionnelles et techniques de 4 modules ERP/MRP et des flux ETL, accompagnement du développement et des modèles SQL jusqu'à la mise en service.

Modules ERP/MRP de Chez André (représentation simplifiée)

  1. Modules ERP/MRP

    • Production
    • Stock
    • Commandes
    • Facturation

  2. Spécifié et validé

    • Modèles SQL et flux ETLvalidés · spécifiés
Quatre modules, production, stock, commandes et facturation, ont été spécifiés avec les flux ETL ; les modèles SQL ont été validés pendant le développement.

01Contexte et problème

  • Production, stock, commandes et facturation séparés, règles de gestion peu alignées dans un contexte retail.

02État initial

  • Quatre domaines fonctionnels à relier dans le même ERP/MRP.

03Conception et contraintes documentées

  • Quatre modules (production, stock, commandes, facturation) spécifiés avec les flux ETL.
  • Modèles SQL et règles de gestion validés pendant le développement.

04Réalisation

  • Environnement : ERP, MRP, retail, SQL Server, ETL.
  • Essais, mise en production et formation de 30 utilisateurs.

05Résultats vérifiés

  • +65 % de productivité et retour sur investissement en 8 mois.

Limites du périmètre

  • Rôle publié : spécification, accompagnement du développement et mise en service. La conception complète de l'application n'est pas revendiquée.
  • Schéma : représentation simplifiée reconstruite à partir des éléments publiés (l'ordre et le sens des flux sont une lecture simplifiée) ; aucun document original ni schéma interne du client n'est publié.
Voir l'étude de cas

BK Systèmes

3 sites · 5 intégrations

Intégration d'un WMS avec des transporteurs et des canaux e-commerce

Rôle personnel exercé

  • Analyste fonctionnel WMS et intégration : spécifications, essais et mise en production de l'intégration.

Intégration du WMS BK Systèmes (représentation simplifiée)

  1. Systèmes tiers

    • 3 transporteurs
    • 2 canaux e-commerce

  2. Intégration

    • Intégration API RESTspécifiée, testée, en production

  3. Cœur logistique

    • WMS Speed3 sites
Le WMS Speed, déployé sur 3 sites, est intégré par API REST à 3 transporteurs et à 2 canaux de commerce électronique ; l'intégration a été spécifiée, testée et mise en production.

01Contexte et problème

  • Flux WMS sur 3 sites à relier à des transporteurs et à des canaux de commerce électronique.

02État initial

  • État initial détaillé non publié : seuls l'environnement et le périmètre d'intégration le sont.Lecture d'architecture

03Conception et contraintes documentées

  • Intégration par API REST de 3 transporteurs et de 2 canaux e-commerce aux flux WMS.

04Réalisation

  • Environnement : WMS Speed, SQL Server, API REST.
  • Spécifications, essais et mise en production sur les 3 sites.

05Résultats vérifiés

  • 3 transporteurs et 2 canaux e-commerce intégrés aux flux WMS de 3 sites.

Limites du périmètre

  • Aucun indicateur chiffré n'est publié pour ce poste ; la conception du WMS lui-même n'est pas revendiquée.
  • Schéma : représentation simplifiée reconstruite à partir des éléments publiés (l'ordre et le sens des flux sont une lecture simplifiée) ; aucun document original ni schéma interne du client n'est publié.

UniDataTransfer

99,9 % d'intégrité

Interopérabilité et migration de données entre SGBD

Rôle personnel exercé

  • Fondateur et architecte solution, BTBSofting : conception du logiciel de migration, du moteur ETL et de la méthode de bascule.

Chaîne de migration UniDataTransfer (représentation simplifiée)

  1. Source

    • HFSQL

  2. Méthode de migration

    • Diagnostic
    • Mapping
    • Synchronisation miroir
    • Bascule

  3. Cibles

    • PostgreSQL · MySQL · MariaDB · SQL Server
Les données HFSQL passent par un diagnostic, un mapping, une synchronisation miroir puis une bascule, vers PostgreSQL, MySQL, MariaDB ou SQL Server, sous le moteur ETL multi-cibles et l'interface d'administration.

01Contexte et problème

  • Les éditeurs WinDev veulent évolutivité et portabilité vers PostgreSQL, MySQL, MariaDB et SQL Server.

02État initial

  • Données HFSQL à migrer vers quatre SGBD cibles.

03Conception et contraintes documentées

  • Moteur ETL multi-cibles et méthodologie en quatre étapes : diagnostic, mapping, synchronisation miroir, bascule.
  • Interface d'administration pour piloter la migration.
  • Décision de conception documentée : la destination logique d'un transfert (schéma, catalogue ou base selon le moteur) est explicite, conservée avec le modèle et chaque tâche ; les anciens modèles ne sont jamais acceptés silencieusement.

04Réalisation

  • Quatre bases cibles prises en charge : PostgreSQL, MySQL, MariaDB et SQL Server.
  • Code organisé en modules : pilotes par SGBD (HFSQL en source via ODBC), moteur de transfert, planificateur, garde-fous de limites, stockage local et télémétrie, avec une interface de bureau.

05Résultats vérifiés

  • Intégrité des données migrées à 99,9 % et bascule moyenne de 30 minutes par client.

Limites du périmètre

  • Logiciel de BTBSofting ; dates de développement non publiées.
  • Schéma : représentation simplifiée reconstruite à partir des éléments publiés (l'ordre et le sens des flux sont une lecture simplifiée) ; aucun document original ni schéma interne du client n'est publié.
Voir l'étude de cas

UDE

Système privé en usage

Architecture logicielle et gouvernance d'un système multi-agents

Rôle personnel exercé

  • Fondateur, architecte produit et concepteur du système.

Couches d'UDE (représentation simplifiée)

  1. Utilisateur

    • Besoin / projet

  2. Gouvernance

    • UDE Engineering Cortexdoctrine · skills · gates

  3. Agents

    • Environnements d'agents

  4. Livraison

    • Code · tests · Git · CImémoire · Experience Gate
Un besoin ou un projet passe par UDE Engineering Cortex (doctrine, skills, gates), qui encadre les environnements d'agents ; la livraison couvre code, tests, Git, CI, documentation, mémoire et Experience Gate.

01Contexte et problème

  • Lorsque chaque agent suit ses propres méthodes, le contexte s'efface entre les sessions et la qualité dépend du modèle utilisé.

02État initial

  • Agents IA sans méthode commune de compréhension, de spécification et de vérification.

03Conception et contraintes documentées

  • Une méthode commune : comprendre, spécifier, construire, vérifier, passer l'Experience Gate, livrer, apprendre.
  • Vérification proportionnée au risque, y compris Experience Gate, et preuve avant de déclarer une livraison terminée.
  • Décision documentée (ADR) : service local en Python (bibliothèque standard) avec base SQLite et interface statique, plutôt que Tauri + Node + Python, Next.js ou Electron, écartés pour leur coût d'installation et d'exploitation.
  • Décision documentée (ADR) : l'environnement d'agents de référence reste un consommateur mince du noyau UDE par une frontière locale versionnée ; le noyau garde l'autorité.
  • Décision documentée (ADR) : un service unique de contexte de projet sépare les opérations exactes sur l'état faisant autorité de la découverte avec provenance, sans présenter une similarité comme une autorité.
  • Couches : utilisateur, UDE Engineering Cortex (doctrine, skills, gates), environnements d'agents, livraison.

04Réalisation

  • Capacités en usage : méthode commune, vérification proportionnée au risque avec Experience Gate, mémoire et apprentissages durables réutilisables d'une session à l'autre.
  • Les décisions d'architecture sont consignées dans des ADR : contexte, décision, conséquences et, selon le cas, alternatives écartées, déclencheurs de réévaluation et retour arrière.
  • Spécifications et preuves de livraison versionnées avec le projet.
  • Génère et valide la traçabilité des exigences jusqu'aux tests.

05Capacités démontrées

  • Capacités en usage ; aucun indicateur chiffré n'est publié pour UDE.Lecture d'architecture

Limites du périmètre

  • Code source privé, documentation produit expurgée ; seules les capacités ci-dessus sont présentées comme implémentées, aucun élément de feuille de route.
  • Schéma : représentation simplifiée reconstruite à partir des éléments publiés (l'ordre et le sens des flux sont une lecture simplifiée) ; aucun document original ni schéma interne du client n'est publié.

Ce que je ne revendique pas

Par transparence, voici ce que ce profil ne revendique pas. Ces éléments restent à démontrer et ne figurent dans aucun CV.

  • Architecture infonuagique (AWS, Azure, Google Cloud)
  • Architecture d'entreprise (TOGAF)
  • Microservices et architecture événementielle
  • Conteneurs et orchestration (Kubernetes)
  • Expertise ERP éditeur (SAP, Infor)
  • Certification d'architecte
  • Intitulé d'architecte chez un employeur tiers (les titres d'architecte mentionnés ici désignent mes propres produits)

Échanger sur un poste d'analyste d'affaires ou d'architecture de solutions

Nemmene Dumesnil répond aux directions TI qui cherchent un analyste d'affaires senior comme aux responsables d'architecture qui cherchent un profil d'architecture de solutions en ERP, intégration et données.

Me joindre