Assistez la maîtrise d'ouvrage d'un projet SI

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 :

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.

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é”.

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é" :

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 :

• “Mon Bon Devis” (vous pouvez télécharger ce dossier au format doc ou au format odt),

• l’ERP ODOO (vous pouvez télécharger ce dossier au format doc ou au format odt).

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

• 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 :

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 !