Besoins et solutions

Définition et rôle

Le cahier des charges est un document contractuel permettant d’organiser la relation entre client et prestataire. Il précise :

• les fonctionnalités de la solution, sous forme de cas d’utilisation prenant en compte les processus métier ;
• les exigences non fonctionnelles : performances, sécurité, ergonomie, accessibilité (handicaps) ;
• les contraintes en termes de budget et de délais ; 
• les caractéristiques techniques : plate-forme d’exécution, interopérabilité…

Il peut être fourni par le client ou rédigé par le prestataire (et validé par le client).

Méthode QQOQCCP

La méthode QQOQCCP permet la collecte exhaustive et rigoureuse de données.

Lettre	Questions	Exemples
Q	de qui, avec qui, pour qui	responsable, acteur, sujet, cible
Q	quoi, avec quoi	outil, objet, résultat, objectif
O	où	lieu, service
Q	quand, à partir / jusqu’à quand, répétition	dates, périodicité, durée
C	comment, par quel procédé	procédure, technique, action, moyens matériel
C	combien	quantités, budget
P	pourquoi	justification, raison d’être

Il faut se poser les questions avec insistance, jusqu’à ce qu’il ne soit plus possible de trouver de réponses supplémentaires, puis consigner ce qui est réellement pertinent dans un document de synthèse.

Cette technique peut être utilisée — en autres — pour l’expression des besoins.

Remue-méninges et cartes mentales

Le remue-méninge (brainstorming) est une méthode de génération collective d’idées, visant à mobiliser rapidement un large panel de perspectives (utilisateurs, développeurs…) pour recueillir et formuler les besoins fonctionnels et non fonctionnels.

C’est un processus itératif qui alterne processus d’idéation et de classement sous la forme — par exemple — de cartes mentales.

L’analyse de la valeur

L’analyse de la valeur consiste à comparer la valeur ajoutée par une fonctionnalité à son coût de développement.

Si on considère le ratio valeur / coût, l’objectif est de favoriser / prioriser les fonctionnalités pour lesquelles il est le plus élevé.

Jeu du planning (planning poker)

Il apparaît régulièrement que le coût associé au développement d’un projet dépasse les ressources allouées. L’objectif du jeu du planning est de maximiser la satisfaction du client et de le responsabiliser dans ses choix :

1. Le client exprime ses besoins (sous forme de cas d’utilisation par exemple).
2. La maîtrise d’œuvre estime le coût (le temps nécessaire) au développement de chaque fonctionnalité (et précise les dépendances entre elles).
3. Le client priorise les fonctionnalités en fonction de leur valeur et du budget.

Enveloppe (budget box)

Selon le même principe que le jeu du planning, la technique de l’enveloppe consiste pour le client à se fixer une limite budgetaire et / ou temporelle et à sélectionner les fonctionnalités qui y tiennent :

• cela favorise la réflexion sur la valeur réelle de chaque fonctionnalité et évite l’effet “liste de courses” où tout semble prioritaire.
• cela limite les risques de dépassement de budget et de délais.

Méthode MoSCoW

La méthode MoSCoW permet de catégoriser les exigences selon leur priorité :

• Must have : indispensable, le projet échoue sans cette fonctionnalité.
• Should have : importante, mais le projet peut fonctionner sans.
• Could have : souhaitable, à inclure si le temps et le budget le permettent.
• Won’t have : exclue de cette version, reportée à une version ultérieure.

L’externalisation consiste à déléguer une partie du projet à un sous-traitant ; cela permet :

• de bénéficier de l’expertise et de l’efficacité du sous-traitant et ainsi de réduire les coûts et délais ;
• d’éviter d’avoir à se former à certaines technologies et de libèrer des ressources pour d’autres projets ;

Cependant, l’externalisation présente certaines limites ; la dépendance à un sous-traitant peut :

• affaiblir l’expertise interne à long terme ;
• engendrer des pertes de contrôle sur les processus ou la qualité ;
• comporter des risques de confidentialité ;

De plus, l’externalisation induit des coûts de transaction (contrat, suivi…), et présente des risques juridiquesa ; le prestataire principal reste responsable vis-à-vis du client.

Le choix d’un sous-traitant certifié ISO-27001 apporte certaines garanties en termes de cybersécurité.

Progiciel

Un progiciel estt une solution logicielle conçue pour répondre à des besoins génériques ; exemple : les PGI (ERP) comme ODOO. Le progiciel doit être paramétré pour répondre aux besoins spécfiques.

Il existe des progiciels dans différents domaines, et certains (les logiciels libres notamment) permettent le développement de modules additionnels / d’extensions pour ajouter les fonctionnalités manquantes.

Recourir à un progiciel permet :

• un déploiement plus rapide et moins coûteux ;
• de disposer d’une solution éprouvée et interopérable (standards) ;
• de bénéficier des mises à jour (correctifs, améliorations) du progiciel ;
• de bénéficier d’assistance technique et de documentation.

Un progiciel, en revanche  :

• peut être surchargé de fonctionnalités inutiles pour le client ;
• introduit une dépendance vis-à-vis de l’éditeur :
  • coûts récurrents : licences, abonnements,
  • risque de verrouillage (lock-in) — le changement de solution est coûteux,
  • évolutions imposées par l’éditeur (fin du support d’une version…).

Développement sur mesure

Un développement sur mesure (ad-hoc) consiste à créer une solution spécifique pour répondre aux besoins du client.

Les avantages d’un développement sur mesure sont :

• l’évolutivité du logiciel ;
• de disposer d’une solution (avantage concurrentiel) — réutilisable ;
• une indépendance vis-à-vis des éditeurs (mais il reste des dépendances au langage de programmation et aux bibliothèques utilisées).

Par contre, un développement sur mesure :

• est plus coûteux et allonge les délais ;
• nécessite plus de maintenance ;
• introduit une dépendance vis-à-vis de l’équipe de développement (turnover…).

Les solutions envisagées doivent prendre en compte le contexte de l’organisation du client et du prestataire :

• compatibilité / interopérabilité avec l’environnement technologique existant,
• compétences disponibles.

L’évolution d’une solution doit également prendre en compte l’existant, en particulier les processus métiers et le système d’information.

IV.2 Comparaison des solutions

Les solutions doivent être comparées selon :

• le coût (acquisition, développement, maintenance) ;
• les délais de mise en œuvre ;
• la simplicité d’intégration et d’utilisation ;
• l’impact sur la performance et la sécurité ;
• la maturité technologique et la pérennité de la technologie (taille de la communauté, réputation de l’éditeur) ;
• la qualité de la documentation et des ressources disponibles.