24/02/2023 Cartographie de

l’architecture
fonctionnel
Expose Groupe 1

Membre

Nantcho fredy

Kouminye natacha ruth

Tsamo zeufack steve jerkey

Njoya derema
Cartographie de l’architecture fonctionnelle

Plan

Cartographie de l’architecture fonctionnelle 1

A.Petit rappel et Introduction …………………………………………………………………2

B.Qu'est-ce que la cartographie fonctionnelle ? ……………………………………………3

i.La cartographie fonctionnelle c'est quoi ? ………………………………………………3

ii.Elle sert a Kwa ? …………………………………………………………………………..3

C.Quatre axes principaux permettent de détailler l’aspect métier : ………………………4

D.Les étapes pour la l’analyse fonctionnelle. ………………………………………………4

1.Identifiez les utilisateurs du système ……………………………………………………4

2.Analysez les données qui sont manipulées par le système………………………… 4

3.Définissez les traitements à effectuer …………………………………………………5

4.Identifiez les interfaces par lesquelles transitent les données …………………………5

E.Conclusion: ……………………………………………………………………………………. 6

Groupe 1 1/6
 A. Petit rappel et Introduction

Les objectifs de l’architecture du SI

L’objectif de l’architecture SI est d’analyser, définir et cadrer l’évolution des systèmes

d’information en fonction de la stratégie d’entreprise, des processus métier et des innovations
technologiques.

L’architecture du Système d’Information se décompose en 4 strates :

• Strate métier
• Strate fonctionnelle
• Strate applicative
• Strate technique ou physique
• L’architecture a vocation à apporter une vue consolidée du SI et à proposer un plan
cohérent pour aligner infrastructure, applications, modélisation fonctionnelle,
besoins métiers et stratégie d’entreprise, tout en prenant en compte l’existant !
• La démarche rejoint un point de vue dont nous sommes convaincus chez Blueway :
l’architecture doit être étudiée de manière descendante. C’est-à-dire que c’est la
stratégie métier qui guide les orientations SI. Les choix métiers ne doivent ainsi pas
être guidés par les contraintes techniques !

L'architecture fonctionnelle d'un logiciel correspond à une description de haut niveau du

logiciel. Cette description facilite les échanges entre les développeurs et les acteurs du
transfert car elle établit une vision partagée du logiciel.

Dans la suite de notre travaill nous allons nous concetre sur la cartographie fonctionnelle

Groupe 1 2/6
 B. Qu'est-ce que la cartographie fonctionnelle ?

i. La cartographie fonctionnelle c'est quoi ?

La cartographie fonctionnelle se représente dans le plan d'Occupation des Sols (POS) qui
correspond à un plan de classement des services SI, au sens fonctionnel et non applicatif, du
système à urbaniser. Le POS est un découpage en secteurs fonctionnels du Système
d'Information suivant les grandes fonctions des acteurs de la recherche. Le plan d'occupation
des sols fonctionnel est le pivot de la démarche d'architecture d'entreprise ; il se transforme et
s'enrichit au cours de l'évolution des services rendus :

• il est indépendant des structures de l'organisation ;

• il est indépendant de l’architecture applicative qui le réalise ;
• il est stable dans le temps.

Comprendre les tenants et aboutissants d’un système d’information est indispensable pour
démarrer un travail d’architecture. La couche fonctionnelle traite de tout ce que fait
l'application : cad ;

• Les données manipulées

• Et comment elle s'inscrit dans son écosystème applicatif.

Sans une définition claire de ces points, impossible de se poser les bonnes questions par la
suite !

La cartographie fonctionnelle est une représentation des fonctions issues de l'analyse des processus
métiers (exemple : gestion des comptes) ;

ii. Elle sert a Kwa ?

• Elle permet d’identifier et comprendre les besoins des projets, puis d’y répondre de la
manière la plus pertinente avec les SI, les données et les processus disponibles.
• Elle identifie également les gaps à combler quand les SI en place ne peuvent y répondre
ou au contraire les redondances de fonctionnalités entre les SI.
• Elle garantit la transversalité de la conception fonctionnelle au niveau de l’entreprise et
non avec une vision unitaire ou silotée d’un seul projet.
• Elle permet aussi de prendre en compte les ambitions du système dans le temps (on
commence avec 10 utilisateurs, mais la cible est d’en servir 10 000) et dans
l’entreprise (pour l’instant on gère uniquement la paye, mais à terme on veut pouvoir
supporter toutes les fonctions RH).

En tant développeur, nous avons souvent envie de nous jeter dans le codage de notre
application. C’est à la fois rassurant et plus facile de partir sur une voie en totale adéquation
avec nos compétences techniques de base. Or, ceci mène à des échecs cuisants : plus on
évite l’analyse fonctionnelle, plus le système défini risque d’être inadapté aux besoins

Groupe 1 3/6
réels des utilisateurs. C’est donc de la responsabilité de l’architecte de prendre du recul, de
freiner ses instincts pour faire l’effort de comprendre la Big Picture.

C. Quatre axes principaux permettent de détailler l’aspect métier :

• Les utilisateurs,
• Les données utilisées,
• Les traitements réalisés,
• Les interfaces avec les autres applications.

D. Les étapes pour la l’analyse fonctionnelle.

Afin de capturer ces informations, vous allez devoir identifier un représentant des métiers ou
interagir directement avec eux.

1. Identifiez les utilisateurs du système

La première étape de l’analyse fonctionnelle est d’identifier qui va utiliser le système que
l’on est en train de définir : des employés de l’entreprise (gestion des habilitations) ? Des
partenaires ? Des clients depuis internet (sécurisation des accès, disponibilité de l’application)
? Où sont-ils situés (gestion des fuseaux horaires) ?
La volumétrie est très importante également : combien vont-ils être au total ? En même
temps ? Y a-t-il des populations « clés » devant être prise en compte en particulier ? Qui va
faire de la consultation uniquement ?
Au-delà d’une liste de questions forcément incomplète, c’est bien la question de l’usage qui
est au cœur de cette première étape.

2. Analysez les données qui sont manipulées par le système

Une fois les utilisateurs bien identifiés, on peut commencer à s'intéresser aux données qui
sont manipulées : D’où viennent-elles ? Quelle est leur sensibilité (confidentialité) ? Sur quels
référentiels s’appuient-elles ? Quel est leur cycle de vie : qui les produit, qui les transforme,
qui les consomme ? Quel est leur format ? Quel est leur niveau de qualité ?
Ces informations vont vous permettre notamment d’affiner la composante sécurité de
l’expression de besoin, autour des composantes DICT détaillées dans la première partie.
Selon la complexité du système considéré, la partie donnée peut revêtir un cadre plus ou
moins important : en particulier, si on traite des problématiques référentielles :
Si on considère une application traitant l’inventaire magasin de boîtes de petits pois (leur
nombre, leur prix, leur emplacement en rayon) qui doit s’interfacer avec l’application gérant
l'entrepôt, on doit particulièrement s’assurer que la notion de « boîte de petit pois » est la

Groupe 1 4/6
même partout. Plus d’une fois, on se rendra compte que côté entrepôt, on gère seulement des
palettes de boîtes et qu’un traitement est nécessaire pour passer d’un système à un autre.

3. Définissez les traitements à effectuer

Maintenant que nous savons qui va utiliser notre système et les données qui sont manipulées,
nous pouvons nous intéresser au cœur : qu’est-ce qu’on fait de tout ça ?
Ici, il est question de lister les grands blocs fonctionnels par type d’usage : gestion
d’inventaire, authentification des utilisateurs, production de rapports... Idéalement, c’est ici
qu’on va associer des notions de performances : telle fonction doit répondre en moins de 3
secondes, tel rapport doit être produit chaque nuit, etc.
Dans la plupart des projets, personne n’est capable de fournir ces indications de manière
explicite et immédiate. C’est souvent une fois le projet déployé qu’il faut revenir à cette
étape et détailler, en s’appuyant sur les premiers retours utilisateurs.

4. Identifiez les interfaces par lesquelles transitent les données

Dernier pan à analyser, les échanges entre les systèmes doivent être caractérisés par 2
éléments : la donnée portée et surtout le sens de transfert de la donnée.
On ne parle pas ici de qui initie quoi techniquement mais bien des applications sources et
cibles Une bonne façon de bien identifier les interfaces et de vous demander qui est le
producteur de la donnée et qui sont ses consommateurs.

Groupe 1 5/6
 E. Conclusion:

Groupe 1 6/6