PROJET SI: SYSTEME D’INFORMATION

Manuel Ntumba

PREMIER CHAPITRE - GENERALITES ET CONCEPTS

I. ESTIMER ET QUANTIFIER LES MOYENS MIS OU À METTRE EN OEUVRE

L'ingénierie de déploiement de dispositifs, de projet ou de prototype, consiste à

introduire à la fois des ressources humaines et techniques.

L’aspect technique se matérialise :

 au niveau des ressources : par l’achat ou la conception de ressources en

ligne afin d’inciter à plus de temps de connexion et d’usages.
 comme soutien à l’initiation à l’usage d’Internet et aux apprentissages :
en mettant en œuvre un dispositif de suivi des utilisateurs, la remise à
niveau en préformation, la création de communautés de professionnels en
post-formation …
 comme appui logistique : en distribuant les supports d’information et de
formation par Internet ou Intranet, en créant un centre de ressources local.

Ces différentes approches ne sont pas équivalentes et demandent des moyens

techniques, humains, organisationnels et managériaux adaptés. De quelles
ressources les responsables du dispositif que vous auditez ont-ils eu besoin ? Ou de
quelles ressources allez-vous avoir besoin pour mener à bien l'ensemble du projet ?
De quoi ont-ils disposé en interne, aussi bien en terme de ressources humaines que
matérielles et logistiques ? Sur quoi pouvez-vous compter pour le développement du
projet dans lequel vous êtes impliqué ? Qu’ont-ils dû trouver à l’extérieur ? Et vous,
que vous faudra-t-il trouver à l'extérieur de votre propre organisation ? Quels
moyens privilégier pour y avoir accès et pourquoi : des achats ? un processus de
location ? l'appel à un (des) prestataire(s) ? ou bien la recherche de partenaires ?
Voici quelques-unes des questions auxquelles il convient maintenant de travailler.

1.1 Développement des ressources en ligne

Il est fort probable que dans les scénarios d’usage que vous venez de privilégier, la
place des ressources numérisées est primordiale. Il s’agit maintenant de vérifier
comment elles ont été mises à disposition des utilisateurs. Ou bien comment allez-
vous les mettre à disposition des utilisateurs : par la mise en ligne de ressources
existantes ? par la conception de nouvelles ressources ? par l’achat de produits
extérieurs ? ou encore par un savant panachage de ces trois modalités ?

Dans tous les cas, vous devrez :

- évaluer l’existant (en interne : ressources propres ou en externe : achat)
- créer éventuellement de nouvelles ressources (en interne ou en vous faisant
aider de prestataires externes)
En ce qui concerne la conception et la production de nouvelles ressources, il
convient d’étudier les compétences impliquées ou à impliquer pour leur réalisation.
En effet, la fabrication de produits multimédias demande plusieurs expertises dans
des métiers divers mais complémentaires : les experts du contenu à transmettre
bien sûr, mais aussi des personnes averties de l'interactivité multimédia sans
oublier les compétences technologiques (développeurs, graphistes et intégrateurs…).

La maîtrise d’un outil de création de didacticiel peut fournir une aide précieuse.
Toutefois, si les projets sont complexes, lourds ou à forte visibilité ou encore, si le
temps manque ou des compétences nécessaires font défaut dans les équipes projet
concernées, il est justifié de rechercher une aide extérieure en faisant appel à un
prestataire.

Dans le cas du prototype comme dans un projet ou un audit, il est utile d’évaluer
les prestations offertes car elles ne sont pas équivalentes d'une société à l'autre, ni
en terme de coûts, de produits finis ou encore de nature des services. Pour aider à
faire le choix ou aider à évaluer les choix déjà faits, voici quelques questions à vous
poser :
- Quelles sont les références des prestataires concernés sur le marché ?
- Quelles compétences professionnelles, les prestataires mettent-il à la
disposition des équipes projet : uniquement des techniciens (informaticiens,
développeurs…) ou une équipe pluridisciplinaire composée aussi d'experts
pédagogiques multimédia ?
- Dans ce cas, quelle liberté donnée pour s’impliquer avec eux dans la
conception et le développement du projet ?
- Avez-vous pu voir ou tester les produits déjà réalisés ? Sur quels
environnements informatiques sont-ils opérationnels et avec quels outils ont-
ils été conçus ? Sont-ils aux normes technologiques du marché ?

1.2 L’infrastructure technique et les solutions logicielles

La faisabilité du dispositif, du projet ou du prototype dépend pour une large part de

l'infrastructure technique choisie pour sa distribution. Est-elle construite
principalement sur l'infrastructure du réseau Internet ou utilise-t-elle aussi le câble,
la télévision, les satellites, les réseaux locaux ? Même si l'utilisation de réseaux
Internet ou Intranet constitue aujourd'hui le modèle de distribution principal, il est
tout à fait possible de concevoir de la mise en ligne de contenus utilisant les TIC en
dehors des réseaux : CD-ROM, télévision, visioconférence, etc ..

Dans le cas où l’architecture technique principale repose sur le Web, se pose la

question des capacités informatiques de ses différents éléments et des conditions
d'accès données aux acteurs du projet (animateurs et utilisateurs notamment).

Le modèle le plus fréquemment rencontré s'appuie globalement sur trois types de

composants :
- un (ou des) serveur(s),
- un réseau (Internet ou Intranet) avec sa bande passante et
- les ordinateurs « clients », eux aussi connectés au réseau.
 Les serveurs
Dans ce genre d'architecture, le serveur est le nœud central de l’infrastructure1. Il
devient indispensable dès que le parc informatique concerne des logiciels lourds et
plus d'une dizaine d'utilisateurs connectés. C'est lui qui gère l’ensemble du
processus de formation, et souvent aussi son organisation. Une définition précise de
ses fonctionnalités est indispensable. Une autre contrainte à ne pas oublier est celle
de sa possibilité à être interfacée avec les autres outils logiciels de l’entreprise
(comme les outils de gestion de performances EPSS, les outils de gestion de
production, de type ERP, des outils de gestion de compétence GPEC, ou des
répertoires comme LDAP (Lightweight Directory Access Protocol), etc.).

La solution choisie doit à la fois, apporter une réponse aux besoins spécifiques
identifiés pour le projet mais aussi démontrer sa capacité à être intégrée et à
évoluer avec un EPN ou un réseau d’EPN.

Les réseaux
Un réseau est un ensemble de dispositifs matériels et logiciels permettant à des
humains de communiquer par deux machines ou plus. Cela passe notamment ( et pour
faire simple) par :
- des interfaces (types d'outils assurant la connexion de la machine au réseau),
- des câblages avec leurs bandes passantes,
- des "paquets" (unité d'échanges de transfert de données entre systèmes),
- des routeurs (machines assurant la circulation optimale des divers paquets
de données sur le (les) réseau(x),
- l'adressage (identification des postes émetteurs et récepteurs).
Tout ceci est régi par des protocoles d'échanges : les protocoles TCP/IP
(Transmission Control Protocol/Internet Protocol) qui définissent un ensemble de
règles permettant la fluidité des échanges d'informations.

Les principales difficultés auxquelles nous avons encore à faire face ici, en France
mais aussi en Europe concernant nos réseaux, sont le manque d’infrastructure, la
disponibilité d'une bande passante suffisante (elle reste encore coûteuse et peu
répandue en dehors des centre fortement urbanisés). Autre point à considérer : la
largeur de la bande passante utilisable, autant pour équiper le serveur que pour
donner l’accès à tous les utilisateurs. Celle-ci influence les choix en matière de
production de contenus et des types de communication mis en œuvre (synchrone,
asynchrone, prise de main à distance, partage d'applications,…). Par exemple, il est
très pénalisant de mettre en place des solutions de formation basées sur de la
vidéoconférence et du streaming vidéo si les utilisateurs finaux ne disposent pas de
la bande passante et de l’équipement nécessaire.

Autre point non négligeable : la sécurité de votre dispositif (sécurité informatique

certes avec ses proxy, ses pare-feux mais aussi sécurisation des données, des
informations recueillies sur les individus). Monter un bon dispositif passe par un
niveau de sécurité qui réponde aux besoins de chacun des utilisateurs.

Les ordinateurs clients

Etre attentif aux conditions d'accessibilité données aux utilisateurs est essentiel au
bon fonctionnement d'un dispositif. Dans quelles conditions les utilisateurs auront-
ils accès à ces solutions ? Par la mise à disposition d'ordinateurs fournis par
l'institution elle-même ou sur le matériel personnel des utilisateurs ? Dans tous les
cas, il convient de vérifier la configuration minima nécessaire :
- le type et la vitesse de calcul du processeur (l’unité de calcul) ;
- la taille de la mémoire ;
- la dimension et la résolution de l’affichage - carte vidéo, moniteur (écran) ;
- les outils de saisie et de contrôle : clavier, souris, tablette graphique, écran
tactile, scanner, numérisation vidéo… ;
- la carte son, les haut-parleurs, le casque ;
- les périphériques d’interface donnés : disque dur, disquette, CD-ROM, DVD ;
- l’accès au réseau - modem pour l’accès distant, carte réseau pour l’accès local ;
- l’imprimante – à jet d’encre ou laser, noire et blanc ou couleur.

Alternatives
Aujourd'hui l'ordinateur n'est plus le seul terminal utilisable et de plus en plus, il est
possible d'intégrer dans les dispositifs d'autres terminaux comme :
- les téléphones portables et leur nouvelles technologies (UMTS),
- les assistants personnels numériques (Personal Digital Assistant) comme le
Psion ou le Palm Pilot,
- les ordinateurs sans fil (wireless),
- les consoles de jeu, qui peuvent se connecter sur l’Internet, envoyer et
recevoir du courrier électronique…

En conclusion de ce point sur les technologies, soulignons que l’évaluation des

solutions mises en place doit prendre en compte le besoin d’accès universel et bon
marché. Il s’agit de voir les possibilités et contraintes tout en s'ouvrant à l'avenir en
choisissant des solutions évolutives. Il n'existe jamais une mais toutes sortes de
solutions possibles parmi lesquelles, il a fallu ou il vous faudra vous positionner. Il
convient de rechercher des solutions qui garantissent en toutes situations :
- les performances attendues,
- la fiabilité,
- l'évolutivité,
- l'interopérabilité avec les autres outils logiciels (respect des normes techniques),
- la convivialité des interfaces et l'ergonomie,
- la facilité de gestion,
- la maîtrise des coûts (investissement et surtout amortissement).

Hébergement de la solution logicielle

Outre le choix des bons outils pour distribuer et manager votre dispositif (accès aux
contenus, communications, travail coopératif, évaluations …), se pose la question
de leur hébergement. Les modèles économiques les plus couramment utilisés
aujourd'hui vont de toutes les formules possibles entre l'hébergement complet en
interne, - avec achat de tous les logiciels et mise à disposition sur serveur
propriétaire - jusqu'à la location totale - avec espaces dédiés sur le serveur d'un
prestataire et délivrance de licences d'utilisation d'un logiciel pour vos apprenants
sur une période donnée (modèle ASP).

L'achat est une solution qui reste encore la voie privilégiée par les grands groupes
mais celle- ci passe par des investissements qui peuvent être lourds en terme de
budgets : recherche et études préalables, acquisition des logiciels mais aussi
installation, paramétrage, déploiement et intégration dans le système d'information
de l'entreprise sans oublier tous les frais liés à la maintenance du dispositif et sa
mise à jour. Par contre, c'est une voie qui donne à l'acquéreur la parfaite maîtrise
de son installation et des modalités de son utilisation.
Les solutions de location (ou ASP), plus légères, correspondent bien à des projets en
démarrage ou en forte évolution. Elles offrent en effet des avantages fort
appréciables dans ce genre de situations : pas de maintenance technique à assurer
(celle-ci est généralement incluse dans le tarif de location), possibilité de mettre fin
à tout moment à votre abonnement comme d'en modifier les termes (augmentation
ou réduction du nombre de licences ou de capacités d'hébergement ..), possibilité de
tester différents systèmes en grandeur réelle avant de faire un choix d'achat,
actualisation et mise à jour en continu des performances du dispositif, accès
automatique aux nouvelles versions logicielles des solutions techniques ou aux
nouveaux services.

Le modèle ASP qui ne fait entrer dans votre budget que des lignes relatives à des
coûts de fonctionnement et non d'investissement, est aussi très intéressant pour
lisser et maîtriser les dépenses d’un projet.

II - IDENTIFIER LES BESOINS EN RESSOURCES HUMAINES

Les ressources humaines sont essentielles pour la bonne conduite d’un projet et à
plus forte raison pour le succès du dispositif à auditer. Pour budgéter le projet et
estimer la durée de sa réalisation, il est nécessaire de construire une cartographie
des compétences à mobiliser ou qui sont déjà mobilisées tout au long de son
déroulement. Cela permet ou a permis de mobiliser au bon moment, les bonnes
personnes, que celles-ci soient en interne ou en externe.

Lorsque vous avez identifié le niveau de motivation des parties prenantes et

commencé à réfléchir à la façon de les impliquer, vous avez sans doute repéré de
nombreuses ressources parmi ces personnes. Il est possible aussi que vous ayez
commencé à percevoir quelques insuffisances. C'est pourquoi, il est nécessaire
d’évaluer l'ensemble des compétences nécessaires tout au long du déroulement du
projet afin d'être certain de pouvoir les satisfaire. Si les ressources humaines
manquent ou ont manqué dans l’environnement immédiat, il existe plusieurs
possibilités pour faire face, par exemple : mobilisation temporaire de personnels
d’autres services, recherche de stagiaires, recherche de prestataires ou encore
construction de partenariats. Tout ceci est soit à évaluer si réalisé, soit à
programmer.

C'est pourquoi nous vous proposons maintenant d'entrer dans une approche
compétences. Vous vérifierez si vous avez trouvé ou non les compétences en interne
et où elles sont localisées (direction, management, enseignants, animateurs, expert
de contenus, chef de projet, service informatique, …) ou si vos interlocuteurs ont dû
les chercher en externe ou si vous devrez en faire autant. Dans ce cas, vous
commencerez à proposer des solutions pour les mobiliser (consultants NTE,
prestataires de solution de téléformation, etc …)

Compétences identifiées Personnes porteuses de ces Trouvées ou à

compétences trouver
 DEUXIEME CHAPITRE - DYNAMIQUE DU PROCESSUS DE DEVELOPPEMENT

I. LES MODELES DE DEVELOPPEMENT

Il s’avère de nos jours, que nous ne pouvons plus avoir une démarche
unique dans le développement de projets informatiques, mais qu’il faut construire
le découpage temporel en fonction des caractéristiques de l’entreprise et du projet.
On s’appuie pour cela sur des découpages temporels génériques, appelés modèles
de développement (process models) ou modèles de cycle de vie d’un projet
informatique. Les principaux modèles sont :
le modèle du code-and-fix ;
le modèle de la transformation automatique ;
le modèle de la cascade ;
le modèle en V ;
le modèle en W ;
le modèle de développement évolutif ;
le modèle de la spirale.

1.1. LE MODELE DU CODE-AND-FIX

C’est un modèle qui repose sur la possibilité d’une détermination facile des
besoins : une première phase de Compréhension du problème est suivie d’une
phase de Programmation ; puis une phase de Mise au point, parfois en
collaboration avec l'utilisateur du futur système, est répétée jusqu’à l’atteinte du
résultat visé.

Le modèle du code-and-fix.
 37

1.2. LE MODELE DE TRANSFORMATION AUTOMATIQUE

C’est un modèle basé sur la possibilité de transformer automatiquement des

spécifications en programmes. L’essentiel de l’effort va donc porter sur une
description exhaustive des spécifications qui devront être complètement validées.
Une succession de cycles Phase de Spécifications – Phase de Validation s’achève
par la phase de Transformation, où s’effectue la génération du code.

Le modèle de la transformation automatique

1.3. LE MODELE DE LA CASCADE

C’est un modèle qui a comme objectif majeur de jalonner (présenter

sobrement) rigoureusement le processus de développement et de définir de façon
précise les rôles respectifs du fournisseur qui produit un livrable et du client qui
accepte ou refuse le résultat. Le découpage temporel se présente comme une
succession de phases affinant celles du découpage classique : Étude de faisabilité,
Définition des besoins, Conception générale, Conception détaillée, Programmation,
Intégration, Mise en œuvre. Chaque phase donne lieu à une validation officielle. Si
le résultat du contrôle n’est pas satisfaisant, on modifie le livrable. En revanche, il
n’y a pas de retour possible sur les options validées à l’issue de phases antérieures.
 38

1.4. LE MODELE EN V

Le modèle en V est une amélioration du modèle de la cascade, qui vise à

réduire ce que l’on a appelé l’ « effet tunnel » : après la conception détaillée, le
commanditaire du projet n’a plus de visibilité sur le projet, car les phases suivantes
relèvent d’une validation technique. Ce n’est qu’au terme de la mise en œuvre que
le projet ressort du tunnel. Or, les livrables ne sont pas toujours ceux attendus,
non pas qu’ils ne soient pas conformes aux spécifications, mais parce celles-ci sont
parfois impuissantes à décrire les attentes et la seule validation de documents est
insuffisante. Le modèle en V propose de mettre en regard les phases de conception
des phases de test. Dans chacune des phases de la première branche du V, on
explicite les critères d’appréciation et d’acceptation du système aux étapes
correspondantes de la deuxième branche du V. Ainsi, l’étude détaillée produira un
jeu d’essai qui sera utilisé pour effectuer la recette fonctionnelle. L’installation sur
un site pilote permettra de valider la définition fonctionnelle du besoin, d’après les
critères exprimés dans cette étape. Le bilan global du projet vérifiera que les
objectifs initiaux formulés dans l’étude d’opportunité ont bien été atteints.

Le modèle en V
 3
9

1.5. LE MODELE EN W

C’est un modèle qui enrichit le modèle en V dans le même esprit

d’anticipation sur le livrable final. La première partie du W vise à dégager avec les
clients des orientations pour la conception ou bien à explorer les possibilités d’une
nouvelle technique. Le développement de maquettes ou prototypes permet une
validation plus concrète des besoins, voire une expérimentation.

Le modèle en W

1.6. LE MODEL EVOLUTIF

Ce modèle est aussi appelé « modèle de développement itératif ». L’objectif de

ce modèle est de construire progressivement le système de façon participative. Il
repose sur l’idée que les besoins ne peuvent s’exprimer qu’après une
expérimentation, même sur un système rudimentaire ou incomplet. Dans ce modèle,
chaque cycle est composé de trois phases : « Détermination des besoins –
Programmation - Expérimentation », aboutit à une nouvelle version du système :
le projet s’arrête lorsque le commanditaire juge le système satisfaisant.
 40

Le modèle évolutif

1.7. LE MODEL EN SPIRALE

Ce modèle repose sur le même principe que le modèle évolutif, mais il

s’inscrit dans une relation contractuelle entre le client et le fournisseur. De ce fait
les engagements et validations présentent un caractère formalisé. Chaque cycle
donne lieu
à une contractualisation préalable, s’appuyant sur les besoins exprimés lors du
cycle précédent. Un cycle comporte six phases :
Analyse du risque ;
Développement d'un prototype (modèle, archétype…) ;
Simulation et essais du prototype ;
Détermination des besoins à partir des résultats des essais ;
Validation des besoins par un comité de pilotage ;
Planification du cycle suivant.

Le modèle en spirale
Le dernier cycle permet de développer la version finale et d'implémenter le logiciel.
 41

II. LA GESTION D’UNE PHASE D’UN PROJET INFORMATIQUE

D’après les normes (ISO10006, PMBOK), les activités de gestion de projet

sont organisées comme des processus (ensembles coordonnés d’activités
aboutissant à un résultat), classés en différents groupes, selon l’objectif : démarrage,
planification, réalisation, contrôle et clôture. Pour le PMI, chaque phase fait l’objet
d’une gestion complète qui met en œuvre les processus des cinq catégories à savoir :

Organisation de la gestion d’une phase

1. Les processus de démarrage : ils ont pour but de lancer officiellement le

démarrage du projet ou l’une de ses phases. Il s’agit de repérer certaines
contraintes particulières (financières, humaines, temporelles, techniques…) et
d’arrêter une stratégie générale de conduite de la phase. Lorsqu’il s’agit de la
première phase du projet, le processus de démarrage comprend la désignation
officielle du chef de projet.
2. Les processus de planification : ils visent à définir et à planifier de façon
précise le travail à réaliser. Ils incluent une estimation des charges et une
recherche de ressources, et ils conduisent notamment à la production d’un
calendrier de travail, avec une répartition des tâches.
3. Les processus de réalisation : ils assurent la coordination du personnel et des
autres ressources dans la réalisation du travail planifié. Ils assurent un suivi du
travail réalisé et centralisent d’éventuelles demandes de changement par rapport
à ce qui avait été planifié.
4. Les processus de contrôle : ils sont mis en œuvre périodiquement. Ils
comprennent la mesure de l’avancement du projet par rapport à sa planification,
la prise de mesures correctives et le traitement des demandes de changement.
Ils organisent également l’acceptation officielle des livrables par le client. Une
activité de contrôle peut ainsi conduire à revoir la planification ou déboucher
sur la clôture de la phase.
5. Les processus de clôture : ils ont pour but d’officialiser l’achèvement d’une
phase. Il est recommandé de formaliser l’expérience acquise sur la phase ou sur
le projet.
 42

III. LA CAPITALISATION DE L’EXPERIENCE D’UN PROJET INFORMATIQUE

L’expérience joue un rôle important dans la construction des connaissances

sur la gestion des projets informatiques. On observe un intérêt croissant pour leur
gestion à un niveau collectif. Un dispositif pour capitaliser les expériences autour
des projets système d'information relève à la fois d’une mémoire de projet et d’une
mémoire d'entreprise14. Les connaissances en jeu dans la gestion de projet ont trois
sources :

1. L'explicitation : dans des ouvrages, dans des supports internes à l'entreprise,

au travers une formation, par des échanges entre individus d'un ensemble de
savoirs partageables par une communauté.
2. La capture des événements et activités lors du déroulement d'un projet.

3. L'engagement personnel d'un individu (en général le chef de projet) dans un

projet et sa perception du déroulement et contexte du projet.

Structuration des connaissances projet

 4
3

Cela conduit à distinguer trois grands ensembles de connaissances : des

connaissances de type référentiel, des connaissances de type trace et des
connaissances de type interprétation. Les premières ont un champ plus large
que le projet, les deux autres sont liées à un projet précis. Les trois ensembles de
connaissances doivent être articulées. Les connaissances de type trace servent en
partie
à alimenter ou faire évoluer les connaissances de type référentiel, en général
éclairées par les connaissances de type interprétation. À l'inverse, des
connaissances de type référentiel peuvent parfois être illustrées par des
connaissances de type trace, c’est-à-dire concrétisées dans des projets réels.

La capitalisation de l’expérience d’un projet informatique interprète 9

propriétés de connaissance pour sa bonne gestion :

Intégration : Développer la charte du projet, la formulation du périmètre et

du Plan. Diriger, Gérer, Suivre, Contrôler et Piloter les changements
Contenu : Planification, Définition, Structure de Décomposition du Travail
(WBS), Création, Vérification et Contrôle.
Délais : Définition, Ordonnancement, Estimation de la Durée des tâches et
des Ressources, Développement et Contrôle de la Planification.
Coût : Planification des Ressources, Estimation des Coûts, Budgétisation et
Contrôle.
Qualité : Planification de la Qualité, Assurance Qualité et Contrôle Qualité.

Ressources Humaines : Planification des RH, Recrutement, Développement

et Gestion de l'équipe projet.
Communications : Plan de Communications, Diffusion de l'information,
Rapport d'Activité et de Performance, Gestion des Partenaires.
Risques : Prévision et identification des Risques, Analyse des Risques
(méthodes qualitative et quantitative), Prévision des Actions Correctrices
Surveillance et Contrôle des Risques.

Approvisionnement : Plan d'Acquisition et de Contractualisation, Réponses et

Choix des Soumissionnaires, Administration et clôture des Pour chaque
processus, activité, ou pratique est réalisé une description des produits en
entrée, des outils et techniques ainsi que des produits.
 TROISIEME CHAPITRE - LES OUTILS DE GESTION DE PROJETS
INFORMATIQUES

Les outils de gestion de projets sont les éléments actifs (voies, moyens ou
instruments) qui permettent d’organiser, de piloter, de développer et de régir une
activité déterminée d’un projet. Dans le cadre de ce cours, il ne sera question que
de deux (2) grandes catégories d’outils de gestion de projets informatiques :
Les méthodes de développement ;
Les techniques de gestion.

I. LES METHODES DE DEVELOPPEMENT

Une méthode définit une démarche en vue de produire des résultats. Par
exemple, les cuisiniers utilisent des recettes de cuisine, les pilotes déroulent des
check-lists avant de décoller, les architectes font des plans avant de superviser des
chantiers. Une méthode permet d’assister une ou plusieurs étapes du cycle de vie
du logiciel. Les méthodes d’analyse et de conception fournissent des notations
standards et des conseils pratiques qui permettent d’aboutir à des conceptions «
raisonnables », mais nous ferons toujours appel à la créativité du concepteur. Il
existe différentes manières pour classer ces méthodes, dont :

La distinction compositionnelle / décompositionnelle : met en opposition

d’une part les méthodes ascendantes qui consistent à construire un logiciel par
composition à partir de modules existants et, d’autre part, les méthodes
descendantes qui décomposent récursivement le système jusqu’à arriver à des
modules programmables « simplement ».

la distinction fonctionnel / orientée objet : Dans la stratégie fonctionnelle un

système est vu comme un ensemble d’unités en interaction, ayant chacune une
fonction clairement définie. Les fonctions disposent d’un état local, mais le
système a un état partagé, qui est centralisé et accessible par l’ensemble des
fonctions. Les stratégies orientées objet considèrent qu’un système est un
ensemble d’objets interagissant. Chaque objet dispose d’un ensemble d’attributs
décrivant son état et l’état du système est décrit (de façon décentralisé) par l’état
de l’ensemble. La décomposition fonctionnelle du haut vers le bas a été
largement utilisée aussi bien dans de petits projets que dans de très grands, et
dans divers domaines d’application. La méthode orientée objet a eu un
développement plus récent. Elle encourage la production de systèmes divisés en
composants indépendants, en interaction.

Dans le cadre de cours, nous distinguerons alors quatre (4) types des
méthodes a savoir :
les méthodes fonctionnelles, basées sur les fonctionnalités du logiciel ;
les méthodes objet, basées sur différents modèles (statiques, dynamiques et
fonctionnels) de développement logiciel.
Les méthodes adaptatives ou Agiles, basées sur le changement des besoins ;
Les méthodes spécifiques, basées sur les découpages temporels particuliers.
 1.1. LES METHODES FONCTIONNELLES

Les méthodes fonctionnelles ont pour origine la programmation structurée.

Cette approche consiste à décomposer une fonctionnalité (ou fonction) du logiciel en
plusieurs sous fonctions plus simples. Il s’agit d’une conception « top-down », basée
sur le principe « diviser pour mieux régner». L’architecture du système est le reflet de
cette décomposition fonctionnelle. La programmation peut ensuite être réalisée soit
à partir des fonctions de haut niveau (développement « top-down »), soit à partir
des fonctions de bas niveau (développement « bottom-up »).

Schéma de la décomposition fonctionnelle

Cette méthode présente comme les inconvénients suivants :

L’architecture étant basée sur la décomposition fonctionnelle, une évolution

fonctionnelle peut remettre en cause l’architecture. Cette méthode supporte
donc mal l’évolution des besoins.

Cette méthode ne favorise pas la réutilisation de composants, car les

composants de bas niveau sont souvent ad hoc et donc peu réutilisables.
 1.2. LES METHODES OBJET

Les approches objet sont basées sur une modélisation du domaine

d’application. Les « objets »sont une abstraction des entités du monde réel. De façon
générale, la modélisation permet de réduire la complexité et de communiquer avec
les utilisateurs. Plus précisément un modèle :

Aide à visualiser un système tel qu’il est ou tel qu’on le souhaite ;

Permet de spécifier la structure ou le comportement d’un système ;
Fournit un guide pour la construction du système ;
Documente les décisions prises lors de la construction du système.

Ces modèles peuvent être comparés avec les plans d’un architecte : suivant
la complexité du système on a besoin de plans plus ou moins précis. Pour
construire une niche, on n’a pas besoin de plans, pour construire un chalet il faut
un plan, pour construire un immeuble, on a besoin d’un ensemble de vues (plans
au sol, perspectives, maquettes). Dans les méthodes objet, on distingue trois
aspects :

Un aspect statique : Dans lequel, on identifie les objets, leurs propriétés et

leurs relations ;
Un aspect dynamique : Dans lequel, on décrit les comportements des
objets, en particuliers leurs états possibles et les évènements qui
déclenchent les changements d’état ;

Un aspect fonctionnel : qui, à haut niveau, décrit les fonctionnalités du

logiciel, ou, a plus bas niveau, décrit les fonctions réalisées par les objets
par l’intermédiaire des méthodes.

Les intérêts des approches objet sont les suivants :

Les approches objet sont souvent qualifiées de « naturelles » car elles sont
basées sur le domaine d’application. Cela facilite en particulier la
communication avec les utilisateurs.
Ces approches supportent mieux l’évolution des besoins que les approches
fonctionnelles car la modélisation est plus stable, et les évolutions
fonctionnelles ne remettent par l’architecture du système en cause.

Les approches objet facilitent la réutilisation des composants (qui sont moins
spécifiques que lorsqu’on réalise une décomposition fonctionnelle).

II. LES METHODES ADAPTATIVES

Les méthodes dites « adaptatives » sont subdivisées en 2 parties notamment :

les méthodes prédictives et les méthodes agiles (adaptatives).
 2.1 LES METHODES PREDICTIVES

Ce sont des méthodes qui correspondent à un cycle de vie du logiciel en

cascade ou en V, sont basées sur une planification très précise et très détaillée, qui
a pour but de réduire les incertitudes liées au développement du logiciel. Cette
planification rigoureuse ne permet pas d’évolutions dans les besoins des
utilisateurs, qui doivent donc être figes dès l’étape de définition des besoins.

2.2 LES METHODES AGILES

Ce sont des méthodes qui correspondent à un cycle de vie itératif, qui

considèrent que les changements (des besoins des utilisateurs, mais également de
l’architecture, de la conception, de la technologie) sont inévitables et doivent être pris
en compte par
les modèles de développement. Ces méthodes privilégient la livraison de
fonctionnalités utiles au client à la production de documentation intermédiaire
sans intérêt pour le client.

Ainsi, Toutes les méthodes agiles prennent en compte dans leur modèle de
cycle de vie trois exigences :
Une forte participation entre développeurs et utilisateurs,
Des livraisons fréquentes de logiciel et ;
une prise en compte de possibles changements dans les besoins des
utilisateurs au cours du projet.

C’est pourquoi toutes font appel, d’une façon ou d’une autre, à un modèle
itératif et incrémental. De plus, elles préconisent en général des durées de cycle de
vie des projets ne dépassant pas un an. Parmi les méthodes agiles, les plus
usuelles ; on peut citer :
La méthode RAD (Rapid Application Development) ;
La méthode DSDM (Dynamic Systems Development Method);
La méthode XP (Programmation eXtrême);
La méthode SCRUM.

LA METHODE RAD

La méthode RAD, est un modèle linéaire (présentoir), structuré en cinq

phases, et dont le modèle itératif intervient à la phase Construction du logiciel en
vu de la séquencer en plusieurs modules Successivement livrés.

La participation des utilisateurs est placée au cœur du cycle. En effet, le

déroulement d’une phase comprend une ou plusieurs sous-phases, et chaque sous-
phase présente une structure à trois temps, dans laquelle la tenue d’une session
participative joue un rôle central. Des travaux préparatoires rassemblent et
construisent le matériau (modèle ou prototype) qui sera ensuite discuté par les
différents acteurs et ajusté.
 LA METHODE DSDM

La méthode DSDM a évolué au cours des années. L’actuelle version

distingue le cycle de vie du système et le cycle de vie du projet. Le premier comprend,
outre les phases du projet lui-même, une phase de pré-projet qui doit conduire au
lancement du projet et une phase post-projet qui recouvre l’exploitation et la
maintenance de l’application.

Le cycle de vie du projet comprend cinq phases, dont deux sont cycliques.
Les flèches pleines indiquent un déroulement normal. Les flèches en pointillé
montrent des retours possibles à une phase antérieure, soit après la phase
Conception et construction, soit après celle de Mise en œuvre.
 Après une Étude de faisabilité, la phase Étude du métier permet, à travers
des ateliers (workshops) entre équipe de projet et manageurs, de définir le périmètre
du projet, avec une liste d’exigences prioritaires et une architecture fonctionnelle et
technique du futur système.

La phase Modélisation fonctionnelle est une suite de cycles. Chacun permet

de définir précisément les fonctionnalités souhaitées et leur priorité. L’acceptation
par toutes les parties prenantes d’un prototype fonctionnel, sur tout ou partie du
périmètre, permet de passer à la phase Conception et construction. L’objectif de
cette phase est de développer un logiciel testé, par des cycles successifs de
développement/acceptation par les utilisateurs.

LE MODELE XP

La méthode XP, focalisée sur la partie programmation du projet, propose un modèle

itératif avec une structure à deux niveaux : d’abord des itérations de livraison
(release), puis des itérations de développement. Les premières conduisent à livrer
des fonctionnalités complètes pour le client, les secondes portent sur des éléments
plus fins appelés scénarios qui contribuent à la définition d’une fonctionnalité.

Après une phase initiale d’Exploration des besoins, un plan de livraison est défini
avec le client. Chaque livraison, d’une durée de quelques mois, se termine par la
fourniture d’une version opérationnelle du logiciel. Une itération de livraison est
découpée en plusieurs itérations de développement de courte durée (deux semaines
à un mois), chacune donnant lieu à la livraison d’une ou plusieurs fonctionnalités
pouvant être testées, voire intégrées dans une version en cours.

De façon plus détaillée, chaque itération de développement commence par

l’écriture de cas d’utilisation ou scénarios (user stories), c’est-à-dire des fonctions
simples, concrètement décrites, avec les exigences associées, qui participent à la
définition d’une fonctionnalité plus globale. Utilisateurs et développeurs
déterminent ensemble ce qui doit être développé dans la prochaine itération. Une
fonctionnalité est ainsi découpée en plusieurs tâches. Les plans de test sont écrits,
les développeurs sont répartis en binôme ; ils codent les tâches qui leur sont
affectées, puis effectuent avec les utilisateurs des tests d’acceptation. En cas
d’échec, on revoit les scénarios et on reprend la boucle. Sinon, on continue jusqu’à
avoir développé tous les scénarios retenus. Une version livrable est alors arrêtée et
mise à disposition, ainsi que la documentation.

LA METHODE SCRUM

La méthode SCRUM emprunte au vocabulaire du jeu le qualificatif des trois phases

du cycle préconisé.

La phase d’Avant-jeu (pre-game), Conception et architecture du système, se déroule

de façon structurée, en général linéaire, et permet de déterminer le périmètre, la
base du contenu du produit à développer et une analyse de haut niveau.

La phase de Jeu (game) est itérative et qualifiée d’empirique, dans la mesure où le

travail effectué ne fait pas l’objet d’une planification. Une itération, dont la durée
oscille entre une et quatre semaines, est appelée un Sprint, en référence à ces
poussées rapides et fortes que les joueurs de rugby peuvent effectuer sur le terrain.
Un Sprint est découpé en trois sous-phases :

Développement (develop) : il s’agit de déterminer l’objectif visé au terme de

l’itération, de le répartir en « paquets » de fonctions élémentaires, de développer et
tester chaque paquet.

Emballage (wrap) : on referme les « paquets » et on les assemble pour faire une
version exécutable. • Revue (review) : une revue élargie permet de faire le point sur
les problèmes et l’avancement.

Ajustement (adjust) : ajusté le travail restant.

La phase d’Après-Jeu (postgame), Clôture, vise à livrer un produit complet et

documenté. Comme dans la première phase, on peut en planifier les tâches et les
dérouler de façon linéaire.
 II. LES METHODES SPECIFIQUES

Certains découpages temporels sont liés soit à une méthode, soit à un type de
projet bien particulier. Nous en proposons deux exemples : le découpage préconisé
pour mettre en place un progiciel intégré et le modèle RUP proposé par la société
Rational Software. A ce stade, nous citerons les méthodes telles que :
La méthode ERP ;
La méthode RUP ;

3.1. LE CYCLE ERP

La mise en place d’un progiciel de gestion intégré, souvent appelé du terme anglo-
saxon ERP (Enterprise Resource Planning) s’appuie sur un découpage spécifique.

En effet, il s’agit de construire, en tirant le meilleur parti du progiciel, un système

améliorant la performance de l’entreprise. Deux étapes doivent donc être menées en
parallèle : Description des processus et Formation au progiciel.

Ensuite, il y a autant de cycles d’analyse — paramétrage — prototypage qu’il y a de

processus. La validation par le Comité de pilotage permet une simulation en
grandeur réelle. Il faut alors prendre en compte ce qui est resté en dehors du
champ couvert par le progiciel.
 3.2. LE MODELE RUP

Le modèle RUP (Rational Unified Process) est représentatif d’une approche

combinant plusieurs modèles. Sa structure fait l’objet d’un assez large accord,
notamment parmi les praticiens. Il peut être lu de la façon suivante :

1. Le cycle est constitué de quatre phases principales, que l’on retrouve

globalement dans toutes les approches descendantes : étude préalable
(opportunité), conception de la solution détaillée (élaboration),
développement de la solution (construction) et mise en œuvre (transition).

2. Il existe six types de tâches qui, au lieu d’être affectées exclusivement à une
phase, se retrouvent à des degrés divers dans chacune des phases. Par
exemple, l’étude des besoins peut apparaître jusqu’à la fin du projet, mais la
plus grande partie est effectuée dans les deux premières phases.
L’implémentation
(développement) a principalement lieu dans la phase de construction, mais
on peut réaliser un prototype dès la première phase. Certaines tâches,
comme la direction de projet, s’effectuent sur toute la durée du projet.

3. Certaines phases peuvent être menées de façon cyclique. Ainsi, l’élaboration

se fait en deux cycles, conduisant par exemple à la production de
spécifications externes (vision utilisateur) et spécifications techniques (vision
développeur).
La construction est itérative et incrémentale. De plus, l’ensemble du modèle
représente un tour de spirale, dans le cas d’une approche globale en spirale.

CONCLUSION

En guise de conclusion, le pilotage et/ou la gestion de projets informatiques est un

ensemble de techniques qui permettent d’identifier, de planifier et de piloter le
développement d’un produit logiciel. Toutefois l’évolution actuelle à fait susciter
l’aspect managériale afin d’avoir une plus grande valeur ajoutée qui permet la
conduite du projet vers la réussite. Ces techniques et outils ne peuvent fonctionner
pleinement que dans le cadre d’une gestion dimensionnée par projet.

En effet, nous avons voulu montrer, dans les différents chapitres de ce cours, qu’il
existe des techniques permettant de maîtriser le management hors hiérarchie
qu’implique une organisation par projet répondant aux nécessités du troisième
millénaire.

Le tout étant d’accepter d’y consacrer les moyens voulus en fonction de l’ambition
du projet. Parce qu’il ne reproduit pas de modèle mais crée des modèles nouveaux,
la conduite par projet est l’outil du passage à une nouvelle forme de progrès:
développer à la fois le potentiel des hommes et celui des métiers de l’entreprise.
Plus qu’une méthode d’organisation, la conduite de projets informatiques
représente une nouvelle approche culturelle pour les entreprises informatiques ;
une approche fondée sur la culture de la transversalité. En ce sens, la conduite de
projets va donc bien plus loin que le fait de faire travailler ensemble des gents
venants de différents métiers sur un objectif commun. C’est à la fois un outil
stratégique de l’entreprise pour répondre aux changements rapides des marchés et
un formidable outil de motivation pour ceux qui y participent comme pour les
métiers, si tous les apprentissages réalisés sont mémorisés. Le tout est d’avoir envie
et de savoir-faire vivre cette transversalité entre les objectifs à court terme des
projets et les objectifs à long terme de l’entreprise. Faire vivre un projet est une
question de méthodes et d’hommes. C’est aussi, pour les entreprises, une question
de volonté.