QQOQCCP, le recueil de besoins en 9 questions élémentaires

Comment définir un projet informatique ?

Après tout, c’est un domaine complexe, que vous ne maîtrisez pas forcément dans sa totalité : il y a des serveurs informatiques à mettre en place, des données financières qu’il serait bien de visualiser à l’écran, et aussi personne n’a envie de recopier toute la liste des salariés de la société dans le nouvel outil…

Stop. Si vous avez lancé un projet informatique de cette façon, sans aucun cadre, sans aucune méthode, vous avez une garantie : celle de l’échec. Il faut structurer votre demande. Comment ?

Les Romains, qui étaient très organisés, sont les premiers à avoir formalisé une méthode de recueil des besoins. Il s’agit du Quis, Quid, Ubi, Quibus auxiliis, Cur, Quomodo, Quando, c’est-à-dire Qui ? Quoi ? Où ? Quand ? Comment ? Combien ? Pourquoi ?, qu’on désigne généralement sous le sigle QQOQCCP.

Ce sont les 7 questions qui permettent de définir les circonstances d’une situation, quelle qu’elle soit, ce qui inclut le domaine informatique. Et pour être exhaustif, on peut ajouter 2 autres questions : « pour qui ? » en plus de qui, ainsi que « avec quoi ? » en plus de quoi. Voilà nos 9 questions !

Et pour bien assimiler son fonctionnement, imaginez que vous vous appelez Caius Septimus et que Jules César vous charge de construire un aqueduc à Barbegal, en Gaule Narbonnaise. En répondant à toutes ces questions, vous êtes assuré d’avoir mis votre projet sur la bonne voie.

1) Pourquoi ?

secheresse-terre-craquelee

Quel est le facteur déclenchant du projet ? Il peut y en avoir plusieurs, par exemple :

  • la cité s’est beaucoup développée et il y a des pénuries d’eau dans certains quartiers
  • une caserne militaire a été implantée pour défendre la ville, ce qui nécessite d’abreuver de nombreux chevaux (le reste de la Gaule ne va pas s’envahir toute seule, rappelez-vous)

 

 

2) Quoi ?

fontaine-rome-jet-eau

Il s’agit du cadre, des objectifs à atteindre :

  • quadrupler le débit d’eau actuellement amené jusqu’à la cité
  • la construction d’une meunerie pour moudre le blé des nombreux champs nécessaires à la croissance de la cité

Le pourquoi est distinct du quoi. Le quoi, ce sont les objectifs matériels à atteindre : on peut les quantifier, on peut leur fixer des dates limites, on peut contrôler leur avancement.

 

3) Pour qui ?

legionnaires-romains-colisee-rome

Listez les utilisateurs ainsi que leurs utilisations. Facile ! me direz-vous. Les citoyens et les militaires viennent, remplissent des amphores, et s’en retournent.

Ha bon ? Et les chevaux, ils boivent au goulot des amphores ?

Non, bien sûr. La réalité est toujours plus complexe que l’image qu’on s’en fait à première vue. Il en va de même pour les projets informatiques : n’oubliez jamais les utilisateurs inopinés, tels les chevaux romains, qui auront besoin de votre projet.

 

4) Qui ?

Si l’aqueduc rencontre un problème inattendu (un terrain boueux par exemple), qui décide s’il vaut mieux étayer la zone ou la contourner ?

jules-cesar-tuileries-paris

  • les ouvriers construisent, mais ne valident pas
  • l’architecte suggère une solution, mais ne valide pas
  • Jules César donne les grandes lignes, mais ne valide pas (il est déjà suffisamment occupé à préparer sa guerre des Gaules)
  • le maître d’ouvrage, c’est-à-dire vous, Caius Septimus, devez prendre les décisions fonctionnelles sur le futur aqueduc : quelle source prendre, quel tracé suivre, à quelle hauteur, etc.

Il est vital pour le projet d’identifier dès le début le preneur de décision, et de le légitimer dans ce rôle. Par exemple, si Jules César passait son temps à remettre en cause vos décisions, le projet n’avancerait pas.

Comment la prise de décision fonctionne-t-elle dans un projet informatique ? Exactement pareil que pour un aqueduc antique !

  • les développeurs construisent, mais ne valident pas
  • l’architecte suggère une solution, mais ne valide pas
  • le sponsor (un top manager) donne les grandes lignes, mais ne valide pas (il est déjà suffisamment occupé à préparer l’adoption du futur projet par toute la société)
  • le responsable fonctionnel (aussi appelé key user, ou product owner) définit les besoins pour son organisation (entreprise, département…), suit le chantier, répond aux questions de fonctionnement au nom de l’ensemble des utilisateurs (qu’il consulte régulièrement)

5) Où ?

Où sera située la solution, et depuis où sera-t-elle utilisée ? La question n’est pas si triviale, qu’elle en a l’air.

table-peutinger-rome

Dans le cas de l’aqueduc de Barbegal (que j’ai pris au hasard, le nom sonnait bien) par exemple, une première branche desservait Arles, et une seconde branche amenait de l’eau à une meunerie, décrite sur Wikipedia comme « la plus grande concentration connue de puissance mécanique du monde antique ».

De la même façon dans le cas d’un projet informatique, il faut se demander :

  • où est située la solution : au siège en France ? mais si le service comptable de la filiale australienne dépend de cette solution pour travailler, et que la connexion internet est coupée ?
  • depuis où sera-t-elle utilisée : le bureau du DG uniquement ? les bureaux de Paris ? la France entière ? l’Australie ? depuis les bureaux de l’entreprise ? en télétravail ? en transit, à l’aéroport ?

6) Comment ?

On a déjà évoqué brièvement les utilisateurs : les citoyens, les militaires, les chevaux. Mais comment vont-ils accéder à l’eau : l’aqueduc va simplement déboucher en plein milieu de la cité, et l’eau coulera en cascades à même le sol ?

Non, bien sûr que non !

fontaine-rome-nuit

Il faut :

  • des fontaines, pour boire et puiser l’eau
  • des lavoirs, pour nettoyer vêtements
  • des thermes, pour se laver
  • des auges, pour faire boire les chevaux
  • etc.

En informatique également, il faut impérativement envisager tous les utilisateurs, donc toutes les utilisations, donc tous les moyens d’accès. Souvent, la mise en place d’une solution informatique questionne l’entreprise sur ses processus métier, car c’est l’occasion d’une remise en question de processus existant depuis des lustres, mais qui ne sont peut-être plus adaptés.

Ne vous limitez pas à un département ou un service dans votre analyse : rares sont les processus qui ne traversent pas une entreprise dans son intégralité (par exemple, le paiement du fournisseur de stylo-billes implique a minima les Services généraux, la Comptabilité, la Finance, la Logistique).

7) Combien ?

sesterces-romains-tresor-treves

Le budget est souvent sous-estimé. Mais ce n’est pas parce qu’une demande a l’air simple qu’elle est simple. Après tout, Google, c’est juste une case de recherche et un bouton.

En effet.

Mais Google, ce sont 60.000 salariés.

 

 

8) Quand ?

cadran-solaire-rome

Faut-il avoir terminé pour Aprilis (avril) ou Quintilis (juillet) ? Oui, ce n’est clairement pas la même chose : à vous de définir les enjeux et les objectifs de date, en accord avec les exécutants évidemment.

Si Rome ne s’est pas faite en un jour, il en va de même d’un projet informatique un tant soit peu complexe.

 

 

9) Avec quoi ?

aqueduc-romain-gard

Un aqueduc n’est jamais construit en ligne droite et à hauteur constante : il s’adapte au relief. Il y a des collines sur lesquelles s’appuyer, des montagnes à contourner, des rivières à enjamber…

De la même façon, de nos jours, il est rare qu’un projet informatique arrive dans une entreprise où aucun système informatique n’est encore en place.

Il faut donc clarifier l’intégration de ce nouveau projet dans le système d’information (le relief) existant :

  • quelles autres projets utiliser comme sources : annuaire des collaborateurs, planning, référentiel des centres de coûts… afin d’éviter aux salariés de devoir ressaisir ces données
  • quels projets alimenter en données : si le projet est lui-même le référentiel d’autres projets existants en aval dans le processus

Le diable est dans les détails

Cette grille d’analyse doit vous servir à définir les principaux éléments de votre projet informatique. Creusez chacun des points qui vous paraissent obscurs afin de tirer la substantifique moelle du projet. Le diable est dans les détails !

N’hésitez pas à prendre conseil auprès d’un oeil extérieur, qui identifiera des problèmes auxquels ne peut pas penser une personne totalement immergée dans le projet.

Le résultat ? Des aqueducs construits il y a plus de 2000 ans sont toujours bien visibles dans le paysage.

Et si on ne fait pas ça ? La tour de Pise, construite il y a 900 ans, menace de s’effondrer depuis la première année de sa construction. Souhaitez-vous un projet informatique « tour de Pise » ?

Votre cahier des charges gratuit !