--- title: "Système de management de la qualité sur Microsoft 365" route: "/references/systemes-qualite" description: "Conception d'un système de management de la qualité global : modélisation métier, UX, delivery agile et reprise de données." --- # Concevoir un système qualité global sur Microsoft 365 Pendant dix-huit mois, Axiome a conçu et développé une part majeure d'un système de management de la qualité destiné à un grand groupe industriel international, dans les secteurs de l'ingénierie aérospatiale et de la défense. Le projet devait remplacer une application vieille de dix ans tout en couvrant un métier fortement réglementé, plusieurs populations et un patrimoine de données réparti entre deux systèmes historiques. ## Modéliser les objets et les flux avant de développer Le projet a commencé par une phase de modélisation des objets métier et des flux. L'objectif était d'identifier au plus tôt les structures de données, les relations, les états, les responsabilités et les workflows nécessaires. Ce travail a permis de rendre explicites des notions que l'application historique avait accumulées au fil du temps : processus, activités, rôles, documents, versions, validations, changements et indicateurs. La modélisation a servi de référence commune au produit, à l'UX, au développement et à la préparation de la migration. ## Un métier complexe à modéliser Le programme devait représenter et faire vivre : - les processus, activités, entrants, sortants et jalons - les rôles et responsabilités - les documents et leurs cycles de vie - les variantes applicables selon les populations - les circuits de changement et d'approbation - une recherche transverse - des tableaux de bord à plusieurs niveaux ## Une architecture de l'information au centre Le cœur du produit reposait sur un modèle de processus, un éditeur graphique, un visualiseur et des mécanismes permettant de relier documents, responsabilités et objets qualité. Cette architecture devait répondre simultanément à neuf référentiels normatifs internationaux couvrant notamment l'aérospatiale, la défense, la sécurité de l'information, les services SI, l'automobile, l'environnement, la santé-sécurité et la lutte contre la corruption. Faire tenir ces référentiels dans une structure commune, sans multiplier les documents ni créer de règles contradictoires, exigeait une modélisation du métier et des relations. Un simple empilement de dossiers SharePoint n'aurait pas permis de représenter cette complexité. ## Un backlog construit à partir de l'existant L'application remplacée avait dix ans. Son périmètre fonctionnel a été repris dans un product backlog afin de ne perdre ni les usages utiles ni les règles métier accumulées. Cette reprise n'était pas une copie à l'identique : chaque élément devait être compris, reformulé, priorisé et confronté à la nouvelle architecture. Le client intervenait directement dans Azure DevOps pour préciser les besoins, compléter les critères, prioriser le backlog et préparer les revues. Ce mode de travail réduisait les intermédiaires entre les utilisateurs, le product owner et l'équipe de réalisation. ## Une équipe Scrum intégrée Le projet avançait par sprints de deux semaines, avec une revue hebdomadaire du produit et des priorités. L'équipe Axiome et les interlocuteurs du client travaillaient dans le même dispositif de pilotage, sur les mêmes éléments de backlog et avec une visibilité partagée sur les décisions. Cette organisation permettait d'ajuster le périmètre sans attendre une livraison lointaine. Les arbitrages fonctionnels, les maquettes, les choix d'architecture et les incréments développés progressaient dans le même rythme. ## Un produit piloté par l'UX et les maquettes L'UX/UI design ne constituait pas une étape de finition. Les maquettes permettaient d'explorer les parcours, de rendre les règles métier visibles et de valider une interaction avant de la développer. Les tests utilisateurs étaient préparés et conduits par l'UX/UI design sur la plateforme de staging du client. Leurs résultats alimentaient le backlog et les sprints suivants. Le projet conservait ainsi un lien direct entre la modélisation du métier, l'interface proposée et l'usage observé. ## Une chaîne de delivery sur plusieurs environnements Le delivery s'appuyait sur cinq plateformes de développement et une plateforme d'intégration interne, complétées par une plateforme d'intégration et une plateforme de staging chez le client. Cette chaîne permettait de contrôler les incréments avant leur présentation, de vérifier leur intégration dans l'environnement du client et d'exécuter les tests utilisateurs sur un contexte représentatif. Les sprints ne produisaient pas seulement des démonstrations : ils alimentaient une trajectoire de delivery structurée entre développement, intégration et validation. ## Reprendre des données issues de deux systèmes déliés Les données historiques provenaient de deux systèmes de bases de données sans liaison directe. Leur structure et leur qualité présentaient de nombreuses incohérences : objets difficiles à rapprocher, relations implicites, formats hétérogènes et valeurs incomplètes. L'équipe a analysé les correspondances nécessaires, défini les règles de conversion et développé un convertisseur de données. Des composants issus de PopCloud ont ensuite été réutilisés pour assurer la création des objets dans la cible et fiabiliser l'exécution de la reprise. Cette migration ne pouvait pas être traitée comme un simple transfert. Elle faisait partie de la conception du nouveau produit, car la structure cible, les relations et les contrôles de qualité dépendaient directement du travail de modélisation mené en amont. ## Une réalisation en mode produit Le programme réunissait modélisation métier, architecture de l'information, pilotage par l'UX, backlog partagé, réalisation agile et reprise de données. La cible visait plusieurs dizaines de milliers d'utilisateurs du groupe. ## Pourquoi cette référence compte Cette référence démontre une capacité à prendre en charge un produit métier complexe dans toutes ses dimensions : comprendre l'existant, modéliser le métier, concevoir les parcours, organiser le delivery, intégrer les équipes du client et préparer une reprise de données difficile. La maîtrise de plusieurs référentiels normatifs est transposable à d'autres secteurs industriels fortement réglementés. La méthode de transformation d'une application historique l'est également pour des organisations qui doivent moderniser sans perdre dix ans de règles, de données et d'usages. ## Échangeons sur votre système métier ou qualité Vous devez remplacer une application historique, modéliser un métier réglementé ou reprendre des données difficiles à relier ? Un premier échange permet d'identifier le périmètre, les risques de transformation et les travaux à engager en amont. [Présenter votre contexte](/contact).