UML est l’acronyme d’Unified Modeling Language, ou langage de modélisation unifié en français. Les diagrammes UML permettent de mieux appréhender un système ou un logiciel complexe grâce à une représentation visuelle de l’architecture du code et des relations entre les différents composants.

Par exemple, l’articulation entre l’authentification d’un client sur un site de commerce, sa recherche d’articles, l’ajout de ces derniers dans le panier et la gestion du paiement peut être schématisée grâce à un diagramme UML.

Les parties prenantes d’un projet logiciel qui ne sont pas impliquées dans sa dimension technique peuvent ainsi facilement comprendre la logique interne du programme, sans aborder les milliers de lignes de code qui le composent.

Les diagrammes UML simplifient donc considérablement le processus d’analyse, transformant un langage informatique en types de pictogrammes standardisés. 

Les diagrammes structurels (ou diagrammes de structure) regroupent six types de représentation, dont les principaux sont les classes, objets, composants et déploiement. Existent également des diagrammes de paquetages et structure composite, moins usités.

Comme son nom l’indique, ce type de diagramme permet de représenter les liens et l’articulation entre différents composants d’un système, selon des points de vue multiples. Ainsi, puisqu’un programme s’appuie sur des nœuds matériels (serveurs, baies, routeurs, ordinateurs, téléphones portables, etc.) pour être opérationnel, il est possible de représenter l’ensemble du système à l’aide d’un diagramme de déploiement.

Bien sûr, cette représentation n’est pas seulement matérielle et c’est le diagramme de classes qui est le plus usité des diagrammes UML, puisqu’il assure un rôle primordial. En effet, il établit la structure statique du système en termes de classes, d’attributs (propriétés) et d’opérations (méthodes ou fonctions). Notions essentielles de la programmation orientée objet, ces éléments s’articulent selon une logique et une hiérarchie précises que le diagramme de classes permet de représenter pour une compréhension plus accessible.

La multiplicité des diagrammes peut être intimidante, mais il n’est pas nécessaire de produire tous les types de représentation. L’important est de choisir le bon diagramme en fonction de l’avancée de votre projet.

Après une phase de brainstorming et pour lister les spécifications d’un système, sélectionnez les diagrammes de cas d’utilisation ou de séquence. À une étape plus avancée telle que la détermination des rôles précis, sélectionnez plutôt le diagramme d’activités, qui s’apparente davantage à une cartographie des processus métiers. Les diagrammes de structure sont quant à eux utiles une fois la phase de production démarrée.

Dans tous les cas, gardez à l’esprit les raisons pour lesquelles vous utilisez un diagramme UML : la modélisation et la représentation des différentes étapes doit servir à la communication et à l’intercompréhension de vos équipes.

Pour illustrer l'utilisation pratique des diagrammes UML dans la conception d'applications, prenons l'exemple fictif d'une entreprise nommée "ACME Web Design", spécialisée dans la création de sites vitrine pour des petites entreprises. Le projet en question consiste à développer un site web pour "Délices Locaux", une boutique de produits artisanaux alimentaires.

Délices Locaux souhaite avoir un site vitrine qui mette en avant ses produits, partage l'histoire de la boutique, et permette aux clients de passer des commandes en ligne. Pour répondre à ces besoins, ACME Web Design décide d'utiliser les diagrammes UML pour conceptualiser et planifier la solution.

Identification des acteurs : Les acteurs principaux sont les clients, le gestionnaire de la boutique, et le système de gestion des commandes.

Cas d'utilisation : Les cas incluent "Parcourir les produits", "Ajouter au panier", "Passer commande", "Gérer les produits" (pour le gestionnaire), et "Traiter les commandes" (pour le système).

Modélisation des données : Les classes principales comprennent Produit, Commande, Client, et Gestionnaire.

• Produit a des attributs comme idProduit, nom, description, et prix.
• Commande inclut idCommande, dateCommande, Client, et une liste de Produits.
• Client contient des informations telles que idClient, nom, adresse, et historiqueCommande.
• Gestionnaire gère les ajouts et les modifications des produits.

Associations : Les relations entre classes sont clairement définies, telles que les commandes associées à des clients et des produits.

Scénarios d'interaction : Chaque cas d'utilisation est développé avec un diagramme de séquence décrivant les interactions entre les acteurs et le système. Par exemple, le scénario "Passer commande" montre comment le client sélectionne des produits, remplit ses informations, et soumet sa commande, tandis que le système vérifie les stocks et confirme la commande.

Flux de processus : Le diagramme d'activité détaille le processus de commande, depuis le choix des produits jusqu'à la confirmation de la commande, en passant par le calcul des frais de livraison et la finalisation du paiement.

Bien que l'UML soit un standard répandu pour la modélisation logicielle, d'autres méthodologies et outils de modélisation peuvent s'avérer plus adaptés selon les spécificités du projet ou les préférences de l'équipe de développement. Nous vous présentons les modélisations les plus communes : 

La cartographie de la chaîne de valeur, ou Value Stream Mapping (VSM) est un outil facilitant l’identification et l’analyse de toutes les étapes de la vie d’un produit ou d’un service, allant de sa conception initiale jusqu’à sa livraison au client final. Grâce à une vue d’ensemble codifiée à l’aide de symboles et de repères visuels, les flux de matériaux, de marchandises et d’informations sont clairement identifiables.

La VSM permet ainsi d’identifier les étapes ne produisant pas de valeur ajoutée dans le processus analysé : l’entreprise peut alors les éliminer afin de gagner en efficacité.

La première étape pour mettre en place une cartographie de la chaîne de valeur dans votre entreprise est d’identifier le processus que vous désirez optimiser. De préférence, optez pour un processus qui comporte un défaut identifié : qualité du produit insuffisante ou mauvaise satisfaction du client, par exemple.

Vient ensuite la collecte des données pour alimenter la VSM. L’ensemble du processus doit être passé au crible en incluant toutes les parties prenantes, ainsi que les exigences et les besoins du client.

Il devient alors possible de créer la cartographie des flux. Des symboles standardisés permettent de visualiser rapidement l’information et d’identifier les gaspillages générés tout au long du processus. Temps d’attente, mauvaise répartition du travail, stocks superflus, ou encore tâches redondantes peuvent ainsi être éliminés.

La démarche proposée par la Value Stream Mapping se fonde sur une observation et une connaissance du terrain. C’est en maîtrisant les différents processus métiers existant au sein de votre organisation que vous rendrez possible leur analyse.

Pour procéder à celle-ci, vous pouvez vous appuyer sur un logiciel de cartographie : chaque carte documente une des étapes de la chaîne de production. La représentation visuelle proposée par la VSM s’intègre alors efficacement dans l’optimisation de votre stratégie d’entreprise.

Pour illustrer concrètement l'efficacité de la Value Stream Mapping (VSM), prenons l'exemple fictif de l'entreprise ACME Lighting, un fabricant de solutions d'éclairage éco-énergétiques. ACME Lighting rencontre des difficultés sur sa chaîne de production d’ampoules, avec des retards dans la livraison des produits finis et une augmentation des coûts de production, liés à un gaspillage considérable des ressources.

La direction décide d’implémenter la VSM pour identifier et éliminer ces dysfonctionnements. Cinq grandes étapes sont identifiables.

Phase 1 : Préparation et cartographie initiale.

Les informations préliminaires sont notées sur la cartographie : nom des principaux clients pour le produit, délais de production estimés et souhaités, quantité à produire, etc. En parallèle, les fournisseurs impliqués dans la production des ampoules sont également listés dans le détail.

Phase 2 : Description des étapes du processus de production.

Chaque étape du processus est consignée. Le nombre de collaborateurs impliqués, les temps de production et d’attente, les ressources utilisées, ou encore le transport d’un site à un autre dans l’usine sont précisément décortiqués.

Phase 3 : Explicitation des liens entre les étapes.

Entre chaque étape doivent être notés les stocks produits et la quantité de pièces en attente. Par exemple, les culots d’ampoule produits par ACME Lighting sont à flux tendus, cela est donc précisé schématiquement sur la cartographie, à l’aide d’un symbole standardisé.

Phase 4 : L’ajout des flux externes.

Tout ce qu’ACME Lighting ne produit pas est ajouté à cette étape. En l'occurrence, le filament de l’ampoule est externalisé par une entreprise tierce. La fréquence de livraison des stocks de filaments et le mode de transport sont consignés.

Phase 5 : L’ajout des flux d’informations et de matière.

Les liens entre les différents interlocuteurs sont explicités : quand intervient l’entreprise pour donner l’ordre de production des culots ? À quelle fréquence s’effectue la commande des filaments ? Combien de temps les ampoules produites sont-elles stockées avant l’expédition au client ? 

Elemate accompagne l’entreprise dans ce suivi : le logiciel permet de documenter l’état des lieux actuel et de centraliser les changements préconisés par l’équipe, tout en impliquant les différentes parties prenantes. Celles-ci peuvent également contribuer à l’élaboration de la cartographie exhaustive des processus pour une meilleure connaissance du terrain, une vision plus globale et contextualisée et une amélioration continue.

Après la mise en œuvre de la VSM, ACME Lighting peut identifier que les retards de production sont dus à des pertes imputables au fournisseur de filaments. Arrivant par voie aérienne, ils supportent mal le voyage et beaucoup sont hors d’usage. Les ampoules ne passent donc pas le contrôle qualité et doivent être produites de nouveau. Les culots étant fabriqués à flux tendu pour neutraliser le besoin en stockage, leur production doit être relancée pour couvrir les pertes.

La cartographie réalisée lors de la VSM permet de mettre en lumière les problèmes de communication entre les différents ateliers d’ACME Lighting et le fournisseur. Cette méthode permet alors de transformer les opérations de production en identifiant tout processus inefficace et en les optimisant. La VSM est aussi un levier pour augmenter la compétitivité et améliorer la satisfaction client.

Bien que principalement utilisée dans le domaine de l’industrie, la Value Stream Mapping se prête à tout type d’entreprise souhaitant optimiser ses différents flux de productions. La VSM est donc aussi bien utilisée aujourd’hui dans le domaine de l’industrie automobile où elle trouve ses origines, que dans l’industrie pharmaceutique, la finance, le management ou encore la production de logiciels informatiques.

Pour être efficace, la VSM doit être alimentée par des données précises concernant l’ensemble du processus. Chacune des étapes qui le composent doit indiquer un temps de cycle, ainsi que le temps d’attente avant la suite de la production.

Au-delà des données temporelles, une VSM complète intègre également :

• Le nombre de parties prenantes impliquées dans le processus (chaque fournisseur, opérateur, équipe de travail doit être documenté, du début de la chaîne jusqu’au client) ; 

• La capacité opérationnelle du processus (combien de pièces peuvent être produites) ; 

• Le pourcentage de défauts tolérés ; 

• Le temps requis pour l’ensemble du processus ; 

• La demande précise du client.

La matrice RACI trouve son origine dans les méthodologies de gestion de projet et de processus. Elle a été développée comme un outil pratique pour résoudre les problèmes de partage des rôles et des responsabilités au sein des projets complexes. 

Les concepts de rôles et de responsabilités sont essentiels dans la gestion de projets pour s’assurer que chaque tâche est correctement assignée et que les membres de l'équipe savent précisément ce qui est attendu d'eux.

Le concept de la matrice RACI repose sur la création d'un tableau où les tâches et les activités d'un projet sont listées en lignes. Les membres de l'équipe ou les rôles apparaissent eux dans les colonnes. Pour chaque tâche, les rôles des membres de l'équipe sont définis en termes de RACI. Voici comment cela fonctionne :

1. Liste des activités/tâches : Identifier toutes les tâches ou activités nécessaires pour réaliser le projet ; 

2. Identification des rôles : Déterminer les rôles ou les membres de l'équipe impliqués dans le projet ; 

3. Assignation des responsabilités : Pour chaque tâche, indiquer qui est Responsable (R), qui est Autorité (A), qui doit être Consulté (C), et qui doit être Informé (I).

Exemple : Matrice-RACI.xlsx

L'histoire de la matrice RACI, comme de nombreux outils de gestion de projet, n'est pas attribuée à une seule personne ou à un moment précis. Cependant, voici un aperçu de son évolution et de son utilisation au fil du temps.

La gestion de projet en tant que discipline a commencé à se formaliser dans les années 1950 et 1960, notamment avec le développement de méthodes comme le PERT (Program Evaluation Review Technique) et le CPM (Critical Path Method). Ces premières méthodologies se concentraient principalement sur la planification et le contrôle des tâches et des délais.

Avec la complexité croissante des projets et des organisations, il est devenu nécessaire de clarifier non seulement les tâches à réaliser, mais aussi les rôles et responsabilités des membres de l'équipe. Dans les années 1970 et 1980, les matrices de responsabilités ont commencé à apparaître comme un moyen de définir et de communiquer ces rôles.

La version RACI, en particulier, a émergé parce qu’elle répondait à la nécessité de distinguer différentes formes de responsabilités au sein d'un projet. Elle a été popularisée dans les années 1980 et 1990 par des méthodologies de gestion de projet plus formelles et des pratiques de gestion de processus. Des organismes tels que le Project Management Institute (PMI) et des méthodologies comme PRINCE2 (Projects IN Controlled Environments) ont joué un rôle crucial dans la diffusion de cet outil.

Chaque personne impliquée dans le projet se voit attribuer un rôle déterminé dans la matrice RACI. Comme un acteur ne peut logiquement pas être à la fois informateur et réalisateur d’une tâche, il est essentiel de bien identifier les rôles et de les distribuer en amont. Pour ce faire, des méthodes telles qu’une cartographie des parties prenantes, ou stakeholders mapping, peut vous aider.

De l’anglais Responsible, le Responsable (ou réalisateur) est chargé d’effectuer une tâche ou une activité telle que définie dans la matrice RACI. S’agissant de l’exécution, il est impératif qu’au moins un acteur soit assigné à ce rôle, sans quoi le travail ne serait effectué par personne.

L’Approbateur supervise un ou plusieurs responsables dans la réalisation des tâches qui leur sont confiées. Assigné à une position de management, c’est lui qui devra rendre des comptes au chef de projet si les délais d’exécution ne sont pas tenus.

Ces deux termes sont parfois inversés, en raison de l’ambiguïté du terme “responsable” en français. Dans le cas où le “Responsable” (R) prend la responsabilité, le A de l’acronyme désigne alors les “Acteurs”, chargés de réaliser une tâche. Nous utilisons ici la version telle que développée en anglais.

Expertes dans un domaine précis, les personnes consultées doivent être sollicitées avant de prendre une décision importante liée à la tâche qui les concerne. En lien direct avec les responsables, les consultants peuvent également orienter ou épauler ces derniers dans la phase de réalisation : il s’agit donc d’une communication à double-sens.

Contrairement au rôle Consulted, un informé est seulement mis au courant de la réalisation d’une tâche et n’est pas tenu de participer directement. Cette information reste essentielle, car, en prenant connaissance de l’avancement du projet, cette personne pourra agir sur les tâches qui la concernent, et pour lesquelles un autre rôle lui a été attribué.

Une entreprise fictive, TechNova, planifie sa restructuration, dans le but d’améliorer son efficacité opérationnelle. Elle opère dans le secteur technologique et souhaite réorganiser les départements de recherche et développement (R&D), de marketing, et de support client pour mieux répondre aux nouvelles exigences du marché, tout en améliorant la collaboration interne.

TechNova a décidé de lancer trois projets majeurs dans le cadre de sa restructuration :

1. Le développement d'un nouveau produit (Projet A)

2. La refonte de la stratégie marketing (Projet B)

3. L’amélioration du système de support client (Projet C)

Pour gérer efficacement ces projets, TechNova utilise une matrice RACI afin de définir clairement les responsabilités et les rôles de chaque membre de l'équipe impliquée.

Voici un exemple détaillé de la matrice RACI pour le projet A (Développement d'un nouveau produit) :

• Responsible (R) : personne chargée d’exécuter la tâche ;

• Accountable (A) : superviseur de la tâche qui valide le travail complet ;

• Consulted (C) : personne dont l’avis est requis ;

• Informed (I) : personne devant être tenue de l’achèvement d’une tâche.

1. Définition des spécifications : L'équipe R&D est accountable pour la création des spécifications du produit, s’appuyant sur les directives du marché. Le chef de projet est responsible de coordonner cette activité, tandis que le directeur technique est consulted pour son expertise technique.

2. Conception initiale : L'Équipe R&D est responsible de la conception, avec le directeur technique comme accountable pour garantir que la conception respecte les normes techniques. Le chef de projet est consulted pour s'assurer que le projet reste aligné avec les objectifs globaux.

3. Validation technique : La responsabilité de la validation technique revient à l'équipe R&D, avec le directeur technique désigné comme accountable pour l'approbation finale. L'équipe support est consulted pour anticiper comment les modifications affecteront le support client.

4. Prototype : Similaire à la conception, mais avec un accent sur la réalisation d'un prototype fonctionnel.

5. Tests internes : L'équipe R&D effectue les tests, tandis que l'équipe support, en tant qu'accountable, valide que le produit fonctionne dans les conditions réelles d'usage client.

6. Plan de lancement : Le chef de projet est responsible de la coordination du plan de lancement, l'équipe marketing est désignée comme accountable pour l'exécution, et le directeur technique est consulted pour s'assurer que les aspects techniques sont pris en compte.

7. Formation produit : L'équipe support est responsible de la formation sur le nouveau produit, tandis que l'équipe R&D est consulted pour fournir les détails techniques nécessaires.

En conclusion, cette matrice RACI aide l’entreprise TechNova à clarifier les rôles et les responsabilités de chacun, minimise les confusions, et permet d’accorder les différents départements vers les objectifs communs, fixés lors de la décision de restructuration.

Comme son nom le laisse penser, la méthode Agile encourage la souplesse dans l’organisation en développant la polyvalence et la communication des acteurs impliqués. Cette philosophie de gestion de projets met l’accent sur la collaboration directe.

Pour combiner l’emploi de la méthode Agile avec une matrice RACI, il est indispensable d’assigner le même rôle à plus d’une personne sur une tâche donnée : cette responsabilité partagée favorisera la communication.

De la même façon, le framework Scrum basé sur la méthode Agile aide les membres d’une équipe à structurer le travail sur des temps courts appelés “sprints”, planifiés en amont. Dans ce contexte, la matrice RACI peut être un outil efficace pour la gestion de ces cycles de développement. En effet, le modèle Scrum applique également des rôles clairs et définis aux membres de l’équipe, permettant aux deux méthodes de se combiner.

Traditionnellement utilisée pour clarifier les rôles et responsabilités dans les projets, la matrice RACI trouve également une application précieuse dans la gestion des processus métiers.

Pour chacune des étapes d’un processus métier, il est possible de clairement identifier qui est responsable (R), qui doit être consulté (C), qui est informé (I), et qui est le garant (A) grâce à l’extension de la matrice RACI à ce domaine. 

L’utilisation de la matrice RACI dans le contexte des processus métiers vous aide à formaliser les rôles pour les opérations quotidiennes et à renforcer l’alignement des équipes avec les objectifs stratégiques de l’entreprise.

Par exemple, dans un processus de développement de produit, la matrice peut spécifier :

• qui dans l'équipe R&D est responsable de la conception initiale ;

• qui dans l'équipe marketing doit approuver le concept ;

• qui doit être consulté pour l'expertise technique ;

• et qui doit être tenu informé de l'avancement du projet.

Cette méthode facilite ainsi la collaboration interdépartementale et assure que toutes les parties prenantes comprennent les attendus et s’impliquent de manière appropriée à chaque étape.

Une réflexion importante préalable à l'adoption de la matrice RACI dans les processus métiers est le niveau de détails à inclure. Alors qu’un tableau des responsabilités classiques offre une vue détaillée de toutes les interactions (R, A, C, I), voire en rajoute certaines selon les besoins (tel que le rôle de Support, par exemple), des versions allégées existent également.

Il est effectivement possible d’engager une gestion de projet avec une matrice qui se concentre uniquement sur les rôles de responsable (ou réalisateur, noté R), et d’approbateur (A). Ces deux éléments suffisent parfois au management, notamment dans des environnements dynamiques où la flexibilité est primordiale.

Commencer par une matrice RA offre alors deux avantages :

• La simplicité et la rapidité de la mise en œuvre : un tableau RA est plus rapide à créer et à mettre à jour, ce qui est idéal pour des projets ou des processus en évolution rapide ; 

• Un focus sur les rôles clés : en se concentrant sur les rôles les plus critiques, une organisation peut s’assurer que les décisions importantes sont prises efficacement, sans se perdre dans la communication de détails moins critiques à ce stade.

Au contraire, si vous optez pour la réalisation d’un tableau RACI classique, les avantages sont alors les suivants :

• La prévention des ambiguïtés : une matrice RACI détaillée prévient les malentendus potentiels en clarifiant en amont toutes les interactions possibles entre les parties prenantes ;

• Une meilleure gestion des risques : en identifiant le rôle de chaque personne ou service, y compris les consultants et les informés, l'organisation peut mieux gérer les risques liés aux communications et aux décisions.