• 15 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 29/06/2020

Démarrez votre analyse de l’existant

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Vous avez récupéré le besoin du client formalisé dans un cahier des charges fonctionnel. Vous êtes prêt à vous lancer ! 

La première étape est de commencer... par ce qui existe déjà ! En analysant l’existant, vous comprendrez mieux quelles sont les contraintes techniques dont vous devez tenir compte pour répondre au besoin de votre client.

“Découpez” votre projet en périmètres logiques

L’une des principales caractéristiques d’un projet SI est qu’il implique généralement plusieurs composants de votre Système d’Information.

Ces composants sont, par exemple :

  • des serveurs ;

  • des bases de données ;

  • des réseaux ;

  • des systèmes d’authentification ;

  • des systèmes de sécurité ;

  • d’autres applications ;

  • etc. 

La première étape de votre analyse sera de tenter de découper votre projet en plusieurs périmètres logiques : on parle de sous-projets.

Un sous-projet est une portion, une brique de votre projet sur laquelle vous pouvez travailler indépendamment des autres. Il peut arriver, en fonction de la taille de votre projet, que vous soyez amené à déléguer le pilotage de chacun de ces sous-projets à d’autres chefs de projet qui travailleront sous votre responsabilité.

Je vous propose un petit exercice pour mettre cela en pratique ! Reprenons le projet de la société “Les Artisans Réunis”. Prenez quelques minutes, un papier et un crayon, et essayez de répondre à cette question avant de poursuivre :

Selon vous, comment pourrions-nous “découper” l’analyse de ce projet ? 

Par exemple, un premier périmètre serait l’extraction des devis validés du logiciel “MonBonDevis”. 🧐

Vous y êtes ? Comparons nos réponses !

Voici ma proposition pour ce découpage :

  • Périmètre n° 1 : Extraction des devis du logiciel “MonBonDevis”.

  • Périmètre n° 2 : Télécollecte du CSV par le serveur du siège.

  • Périmètre n° 3 : Traitement des CSV par le serveur et injection dans l’ERP.

  • Périmètre n° 4 : Développement d’une application web.

Que remarquez-vous avec ce découpage ?

Eh bien oui : la même logique a été utilisée pour rédiger le cahier des charges fonctionnel. 😃 Vous verrez avec le temps que c’est généralement le cas avec les projets SI…

Dans la suite de ce chapitre, nous analyserons, point par point, les composants qui entrent en jeu dans notre future solution. Ces composants techniques sont :

  • la sécurité ;

  • le système d’exploitation ;

  • l’hébergement ;

  • les middlewares ;

  • le framework ;

  • l’application et les données.

Pour chacun, nous recherchons systématiquement les contraintes techniques imposées par le cahier des charges fonctionnel, l’existant, ou les règles dictées par l’entreprise.  

Là encore, aucune méthode n’est meilleure qu’une autre, je vous livre deux options tout à fait comparables.

  • La première : considérer un périmètre projet et analyser tous les composants techniques avant de passer au sous-projet suivant.

  • La seconde : considérer un composant technique et l’analyser pour tous les périmètres avant de passer au point suivant.

Pour ma part, je suis plus à l’aise avec la seconde option. C’est donc celle-ci que je vais utiliser dans la suite de ce cours.

Cernez les aspects liés à la sécurité du projet

Démarrons par le composant technique “sécurité”.

Qu’entendons-nous par “aspect sécurité” du projet ?

Ce sont par exemple :

  • les règles relatives aux droits d’accès des utilisateurs ;

  • le fait qu’une application soit accessible depuis internet ou non ;

  • les protocoles de communication à utiliser ;

  • etc.

À partir de notre cahier des charges fonctionnel, essayons d’extraire les aspects sécurité pour remplir la colonne “Contraintes fonctionnelles” de notre tableau.

Prenons les périmètres projet 1, 2 et 3. Nous comprenons à la lecture du CCF que les traitements seront exécutés automatiquement. Cela implique donc la nécessité que ces traitements soient exécutés par un utilisateur technique, c’est-à-dire un utilisateur système… “non humain”.

Prenez quelques minutes pour réfléchir au périmètre 4 et remplissez votre tableau.

OK… comparons notre travail ! Voici mon analyse des contraintes fonctionnelles pour le composant technique "Sécurité" :

Statut analyse

Périmètre projet

Contraintes fonctionnelles

En cours

1-Extraction des devis validés du logiciel “MonBonDevis”

Exécution automatique

=> par l'utilisateur technique

En cours

2-Télécollecte du CSV par le serveur du siège

Exécution automatique

=> par l'utilisateur technique

En cours

3-Traitement des CSV par le serveur et injection dans l'ERP

Exécution automatique

=> par l'utilisateur technique

En cours

4-Application de suivi des flux

Accessible sur le réseau de l'entreprise uniquement

Accessible au travers d'un navigateur web

Accessible aux utilisateurs déclarés dans l’application et ayant un rôle défini.  

Pour le périmètre 4, je reprends les règles d’accessibilité de l’application de suivi de flux, précisées elles aussi dans le cahier des charges :

  • l’application doit être accessible sur le réseau de l’entreprise uniquement ;

  • avec un navigateur web ;

  • et uniquement aux utilisateurs déclarés et ayant un rôle défini. 

Est-ce que ça va jusque là ? OK, on continue !

Dans un deuxième temps, vérifions dans notre écosystème quelles sont les “contraintes imposées par l’existant et les règles de l’entreprise”.

Pour identifier les “Contraintes liées à l’existant”, il faut réaliser une analyse de l’existant. Il nous faudra donc également des informations “technico-fonctionnelles” sur les applications existantes impliquées dans le projet. Il s’agit des dossiers techniques de nos applications qui contiennent, entre autres, des détails sur :

  • les fonctionnalités ;

  • les composants de l’architecture ;

  • des informations à destination du support.

L’objectif est d’avoir une parfaite compréhension de l’existant pour mieux y intégrer la solution que vous proposerez. Dans notre cas, nous avons à notre disposition les dossiers de :

Parcourez ces documents pour remplir votre tableau. Voici mon analyse des contraintes liées à l'existant pour le composant technique "Sécurité" :

Statut analyse

Périmètre projet

Contraintes liées à l'existant

En cours

1-Extraction des devis validés du logiciel “MonBonDevis”

N/A

En cours

2-Télécollecte du CSV par le serveur du siège

N/A

En cours

3-Traitement des CSV par le serveur et injection dans l'ERP

Alimentation de l'ERP via l'API fournie

Envoi des factures au prestataire éditique au même titre que les autres documents de l'entreprise

En cours

4-Application de suivi des flux

N/A

  • Pour les périmètres projets 1, 2 et 4, il n’y a pas d’existant. En effet, c’est l’objet de notre projet ! Je mets donc “N/A” pour “Non Applicable”.

  • Pour le périmètre 3, en revanche, la documentation de l’ERP ODOO précise que l’accès aux données se fait obligatoirement via une API fournie et précise également le rôle du partenaire éditique. Je le reporte donc dans mon tableau.

Poursuivons avec les colonnes “Contraintes de sécurité” et “Contraintes d’architecture”. “Les Artisans Réunis” est une structure plutôt bien organisée ! Vous trouverez sans peine, sur l’intranet de la DSI, les “Règles d’architecture et de sécurité”. Et ô miracle ! Le document semble être à jour et maintenu régulièrement. Vous pouvez télécharger ce document au format doc ou au format odt.

Dans un premier temps, parcourez ce document. Il est composé de plusieurs parties.

Dans la partie “Sécurité”, vous trouverez des informations relatives à vos obligations, concernant par exemple :

  • les droits d’accès aux applications, bases de données, etc. ;

  • les aspects antivirus ;

  • l’ouverture/fermeture des ports ;

  • les règles de firewall ;

  • etc.

Dans la partie “Architecture”, vous trouverez par exemple :

  • les règles de nommage des composants de votre SI ;

  • les diagrammes d’architecture ;

  • les règles d’architecture relatives à la criticité des applications ;

  • les règles de sauvegarde ;

  • les plans d’adressage IP ;

  • les règles relatives aux choix d’architectures (systèmes d’exploitation, bases de données, frameworks, etc.) ;

  • et probablement de nombreuses autres informations. 

Complétez votre tableau avec votre analyse des règles d’architecture et de sécurité de l’entreprise.

C’est fini ? Comparons nos analyses :

Périmètre projet

Contraintes de sécurité

Contraintes d'architecture

1-Extraction des devis validés du logiciel “MonBonDevis”

Utilisateur applicatif : user_batch_dvf
Utilisateur base de données : user_dba_dvf
Utilisateur LDAP : user_ldap_dvf

Trigramme pour cette nouvelle application : DVF
Connexion au serveur LDAP

2-Télécollecte du CSV par le serveur du siège

Protocole préconisé = SFTP
user SFTP : user_sftp_soc001
Ouverture du port 22 sur les serveurs agence

Trigramme ERP
Connexion au serveur LDAP

3-Traitement des CSV par le serveur et injection dans l'ERP

L'accès à l'API se ferra avec l'utilisateur technique : "user_app_erp".

Trigramme ERP
Connexion au serveur LDAP

4-Application de suivi des flux

Utilisateurs technique à créer auprès de l'équipe sécurité : (user_app_asf - user_dba_asf - user_ldap_asf)
Gestion des accès par LDAP
Port 443 (HTTPS)
Certificat SHA256
Protections contre les injections

 Trigramme pour cette nouvelle application : ASF
Application C3
Stratégie de sauvegarde "Application C3"

J’ai relevé, dans la colonne “Contraintes de sécurité”, toutes les informations relatives aux droits d’accès pour chacun des périmètres projet. Et, lorsque cela était nécessaire, j’ai également relevé les informations relatives aux protocoles de communication et aux ports utilisés.

Dans la colonne “Contraintes d’architecture”, j’ai relevé : 

  • les trigrammes des applications (ils sont utiles pour les comptes techniques) ;

  • les informations de connexion à ma disposition ;

  • les aspects sauvegarde. 

En résumé

Nous avons démarré notre analyse du cahier des charges fonctionnel ! Nous avons découpé le projet en sous-projets et complété notre tableau d’analyse pour le premier composant technique : la sécurité. Il vous reste maintenant à compléter ce tableau pour chacun des composants afin d’avoir une vision globale de votre analyse.

Pour cela, rendez-vous dans le chapitre suivant où nous passerons en revue chacun de ces composants. À tout de suite !

Exemple de certificat de réussite
Exemple de certificat de réussite