3ème année
Les 5 étapes d’un projet numérique… expliquées avec une pizza 🍕
Quand on commence un projet informatique, on a souvent envie de commencer directement à programmer.
Pourtant, le développement ne vient qu’après plusieurs étapes essentielles.
Avant d’écrire du code, il faut comprendre ce que veut réellement l’utilisateur, imaginer la solution, vérifier qu’elle est réalisable et seulement ensuite la construire.
Ce n’est pas « les cinq phases universelles de toute gestion de projet ». Le cours de conduite de projet présente déjà le cycle de vie général : initialisation, planification, exécution, clôture. Ici, nous allons traduire ce cycle de vie en une méthode concrète pour un projet de développement ou de multimédia.
Pour comprendre ce processus, prenons un exemple beaucoup plus simple :
Nous allons fabriquer une pizza. 🍕
Notre projet numérique va suivre 5 grandes étapes :
Besoin → Analyse → POC → Développement → Livraison
Vue d’ensemble : projet numérique vs pizza
Le message le plus important de ce cours n’est pas la liste des étapes. C’est qui valide quoi, et à quel moment. Chaque étape existe pour éviter de découvrir trop tard une erreur qui aurait pu être détectée beaucoup plus tôt.
| Étape | Projet numérique | 🍕 Pizza | On valide ? |
|---|---|---|---|
| 1. Besoin | Quel problème faut-il vraiment résoudre ? | Quelle pizza le client veut-il vraiment ? | ✅ Besoin compris par l’utilisateur |
| 2.A Analyse fonctionnelle / UI | À quoi ressemblera la solution ? Que doit-elle faire ? Comment l’utilisateur interagit-il ? | On montre une photo : « C’est bien ça que tu imagines ? » | ✅ Maquette validée par l’utilisateur |
| 2.B Analyse technique | Comment allons-nous la réaliser ? Langage, base de données, architecture, API, contraintes. | Recette de la pâte, fromages, température, matériel. | ✅ Analyse validée par l’équipe technique |
| 3. POC | Le point le plus risqué fonctionne-t-il vraiment ? | Notre four atteint-il la température ? On teste une mini pâte. | ✅ Faisabilité technique |
| 4. Développement | On construit la solution. | On prépare et on cuit la pizza. | Réalisation (on produit, on ne cherche plus) |
| 5. Livraison | L’utilisateur teste et donne son avis. | Il regarde, il goûte, il commente. | ✅ Satisfaction de l’utilisateur |
Si on saute une validation, on cuisine trop tôt. En développement, c’est ouvrir VS Code avant d’avoir compris la commande.
1. Le besoin : qu’est-ce que l’utilisateur veut vraiment ?
Un utilisateur n’exprime pas toujours directement son besoin.
Très souvent, il donne déjà une solution :
« Je veux une application. »
ou une demande encore très vague :
« Il faudrait quelque chose pour gérer les réservations. »
Le travail du chef de projet ou de l’analyste consiste donc à poser des questions pour comprendre le vrai problème à résoudre.
Une technique simple consiste à demander plusieurs fois :
Pourquoi ?
L’objectif n’est pas d’ennuyer l’utilisateur, mais de remonter progressivement jusqu’à son besoin réel.
Pour aller plus loin sur ce point — pourquoi un utilisateur ne peut pas toujours formuler ce dont il a besoin — lire Pourquoi analyser a besoin de ta créativité de développeur.
🍕 Avec notre pizza
Imaginons cette discussion :
— Qu’aimerais-tu manger ?
— Une pizza.
La réponse est encore beaucoup trop vague.
— Quel type de pizza ?
— Une pizza cuite au feu de bois.
Nous avançons.
— Avec quoi dessus ?
— Quatre fromages italiens.
Encore une question :
— Tu la préfères comment ?
— Avec une pâte très fine.
Nous pouvons maintenant reformuler le besoin :
Tu veux donc une pizza quatre fromages, de style italien, avec une pâte fine de type romaine et cuite au feu de bois.
L’utilisateur peut alors confirmer :
« Oui, c’est bien ce que je veux. »
Cette reformulation est très importante. Tant qu’il n’a pas dit oui, le besoin n’est pas validé.
En informatique, un problème mal compris donnera presque toujours une mauvaise solution, même si celle-ci est parfaitement programmée.
2. L’analyse : à quoi ressemblera la solution et comment allons-nous la réaliser ?
Lorsque le besoin est compris, nous devons imaginer la solution.
Cette étape comporte généralement deux parties. L’une montre ce que l’on veut produire, l’autre explique comment on pense pouvoir le produire.
A. L’analyse fonctionnelle / UI
Nous voulons montrer à l’utilisateur à quoi ressemblera la solution, et surtout ce qu’elle doit faire : les actions, les écrans, le parcours.
Une UI (interface utilisateur) est la représentation visuelle de cette solution. L’étape est plus large qu’un « joli écran » : on définit le comportement, puis on le rend visible.
Pour une application ou un site web, nous pouvons réaliser :
- des croquis ;
- des wireframes ;
- des maquettes ;
- des écrans ;
- un prototype visuel.
L’objectif n’est pas encore de programmer.
L’objectif est de pouvoir demander à l’utilisateur :
« Si nous réalisons ceci, est-ce bien ce que tu imaginais ? »
L’utilisateur doit pouvoir valider cette proposition.
🍕 Avec notre pizza
Nous recherchons plusieurs exemples de pizzas quatre fromages italiennes.
Nous montrons une photo au client :
« Est-ce que tu imagines quelque chose comme ceci ? »
Il peut répondre :
« Oui, exactement. »
ou :
« Non, je voulais une pâte beaucoup plus fine. »
Il vaut mieux découvrir cette différence maintenant qu’après avoir préparé vingt pizzas !
B. L’analyse technique
Une fois que nous savons ce que nous voulons obtenir, nous devons réfléchir à la manière de le réaliser.
Pour un projet informatique, nous pouvons nous demander :
- quel langage utiliser ?
- quelle base de données ?
- quelle architecture ?
- quels services ou API ?
- quelles bibliothèques ?
- quel matériel ?
- quelles contraintes techniques ?
- quels problèmes risquons-nous de rencontrer ?
Cette analyse est généralement discutée et validée par l’équipe technique.
🍕 Avec notre pizza
Nous cherchons maintenant :
- la recette de la pâte romaine ;
- les quatre fromages appropriés ;
- la température du four ;
- le temps de cuisson ;
- la manière de préparer la sauce ;
- le matériel nécessaire.
Nous savons maintenant ce que nous devons produire et comment nous pensons pouvoir le produire.
Mais il reste une question importante :
Est-ce que cela va réellement fonctionner avec notre matériel et nos contraintes ?
C’est là qu’intervient le POC.
3. Le POC : est-ce vraiment possible ?
POC signifie Proof of Concept, ou preuve de concept.
Le POC est une petite expérimentation destinée à vérifier qu’une idée technique fonctionne réellement.
Ce n’est pas encore le produit final.
On teste uniquement les éléments sur lesquels nous avons un doute ou qui présentent un risque.
Pour le détail du concept, voir aussi POC – Proof of Concept.
🍕 Avec notre pizza
Nous avons trouvé une excellente recette de pâte.
Mais notre four peut-il réellement atteindre la température nécessaire ?
Nous allons donc faire un test.
Nous préparons :
- une petite quantité de pâte ;
- un peu de sauce ;
- quelques ingrédients ;
- une cuisson avec notre propre four.
Nous observons le résultat.
La pâte est-elle suffisamment fine ?
La cuisson fonctionne-t-elle ?
Le résultat ressemble-t-il à ce que nous voulons produire ?
Si oui :
Notre solution technique est validée.
Si non, nous retournons à notre analyse et cherchons une autre solution.
En informatique
Un POC pourrait par exemple permettre de vérifier :
- qu’une caméra peut reconnaître un objet ;
- qu’une API fournit les informations dont nous avons besoin ;
- qu’un serveur peut supporter la charge prévue ;
- qu’une technologie fonctionne avec notre matériel ;
- qu’un algorithme produit un résultat suffisamment précis.
Le POC permet donc de réduire le risque avant de développer tout le projet.
4. Le développement : maintenant, on produit !
À ce stade :
- le besoin est compris ;
- l’utilisateur a validé ce que nous voulons construire ;
- l’équipe technique sait comment le construire ;
- les principaux risques techniques ont été testés.
Nous pouvons commencer le développement.
C’est seulement maintenant que nous construisons réellement la solution.
Les développeurs vont transformer les analyses et les maquettes en une application fonctionnelle.
🍕 Avec notre pizza
Nous connaissons :
- la pâte ;
- les ingrédients ;
- la quantité de fromage ;
- la température ;
- le temps de cuisson ;
- la présentation souhaitée.
Nous pouvons donc produire notre pizza quatre fromages.
Et si nous devons en préparer plusieurs, nous pouvons reproduire la même méthode.
Nous ne sommes plus en train de chercher la recette.
Nous produisons.
5. La livraison : est-ce que l’utilisateur est satisfait ?
Le développement terminé ne signifie pas que le projet est terminé.
Il faut encore tester la solution et la présenter à l’utilisateur.
Celui-ci doit pouvoir vérifier que la solution répond réellement à son besoin.
🍕 Avec notre pizza
Nous servons enfin la pizza au client.
Il la regarde.
Il la goûte.
Et il nous donne son avis.
« Très bonne, mais j’aimerais une pâte encore légèrement plus croustillante. »
Cette remarque est intéressante.
Elle ne signifie pas nécessairement que le projet est un échec.
Elle permet d’améliorer notre produit.
Nous pouvons modifier légèrement notre technique de cuisson et améliorer la prochaine pizza.
Un projet est donc une boucle
Notre processus peut être représenté simplement :
- BESOIN — Que devons-nous réellement résoudre ?
- ANALYSE — À quoi ressemblera la solution et comment allons-nous la construire ?
- POC — Notre idée technique fonctionne-t-elle réellement ?
- DÉVELOPPEMENT — Construisons la solution.
- LIVRAISON — Testons-la avec l’utilisateur et récoltons ses retours.
↻ Puis améliorons-la.
La livraison peut donc générer de nouveaux besoins ou des améliorations.
Et le cycle recommence.
Les points de validation à retenir
| Avant de passer à la suite | Qui dit oui ? |
|---|---|
| Besoin compris et reformulé | ✅ utilisateur |
| Analyse fonctionnelle / maquette / UI | ✅ utilisateur |
| Analyse technique | ✅ équipe technique |
| POC | ✅ faisabilité technique |
| Développement | réalisation |
| Livraison | ✅ utilisateur |
Une règle à retenir
Il serait absurde de préparer vingt pizzas avant de demander au client quel type de pizza il voulait.
En développement, c’est exactement pareil.
Si nous commençons directement à programmer sans comprendre le besoin, nous risquons de passer beaucoup de temps à construire…
une excellente solution à un problème que personne n’avait demandé de résoudre.
🍕 Avant de cuisiner, comprendre la commande.
Avant de programmer, comprendre le besoin.
