Plan de projet informatique : modèle pour un logiciel
Un plan de projet informatique qui prévoit la recette, la cession des droits et le retour arrière avant la première ligne de code.
Fait partie de nos Modèles de plan de projetgratuits.
Votre téléchargement a commencé.
Pas de démarrage ? Réessayer le fichier Word ou obtenir le PDF.
1.Présentation du projet
| Nom du projet | {{Nom du projet}} |
|---|---|
| Commanditaire | {{Commanditaire / décideur}} |
| Chef de projet | {{Chef de projet}} |
| Date de début | {{Date de début}} |
| Date de fin visée | {{Date de fin visée}} |
| Statut | {{Non démarré / Conforme au plan / En risque}} |
Ce bloc reste en page une : le projet, son pilote et son état visibles d’un coup d’œil. Un seul chef de projet et un seul commanditaire, celui qui peut réellement trancher.
2.Objectifs et critères de réussite
- Mettre {{logiciel ou lot}} en production le {{date}} avec {{fonction principale}}
- Qualité : {{par exemple aucune anomalie bloquante ouverte à la recette}}
- Critère de réussite : {{usage, délai de traitement, part des dossiers traités dans l’outil}}
Écrivez des objectifs mesurables — « nouveau tunnel de paiement en ligne en semaine 39, taux d’erreur sous 1 % » plutôt que « améliorer le paiement ». Si vous ne pouvez pas dire si c’est atteint, ce n’est pas un objectif.
3.Périmètre
Dans le périmètre
- {{Fonctions du premier lot selon le cahier des charges}}
- Tests, recette et passage en exploitation
- Documentation d’exploitation et guide utilisateur
Hors périmètre
- {{Fonctions renvoyées à un lot suivant}}
- {{Interface qui reste manuelle pour l’instant}}
- {{Données historiques non reprises}}
C’est le hors-périmètre qui empêche réellement la dérive. Écrivez noir sur blanc ce que tout le monde suppose inclus et qui ne l’est pas.
4.Jalons et calendrier
| Jalon | Responsable | Date cible | Statut |
|---|---|---|---|
| Cahier des charges et critères de recette validés | {{Commanditaire}} | {{Date}} | Non démarré |
| Lot 1 livré complet sur l’environnement de recette | {{Prestataire}} | {{Date}} | Non démarré |
| Recette prononcée, procès-verbal signé | {{Maîtrise d’ouvrage}} | {{Date}} | Non démarré |
| Mise en production et passage en exploitation | {{Exploitation}} | {{Date}} | Non démarré |
Les jalons sont des points de contrôle, pas des tâches : quelques dates où l’on répond par oui ou non à « est-ce livré ? ». Un responsable par jalon.
5.Tâches et lots de travaux
| Tâche | Responsable | Début | Échéance | Statut |
|---|---|---|---|---|
| Fixer les critères de recette par fonction et désigner les signataires du procès-verbal | {{Commanditaire}} | {{Début}} | {{Échéance}} | À faire |
| Prévoir au contrat la cession des droits sur le code et la documentation | {{Achats / juridique}} | {{Début}} | {{Échéance}} | À faire |
| Écrire les cas de test à partir du cahier des charges | {{Maîtrise d’ouvrage}} | {{Début}} | {{Échéance}} | À faire |
| Écrire et répéter la procédure de retour arrière | {{Exploitation}} | {{Début}} | {{Échéance}} | À faire |
| Informer et consulter le CSE si l’outil permet un contrôle de l’activité | {{Direction}} | {{Début}} | {{Échéance}} | À faire |
Découpez le travail en tâches suivables sur une semaine au plus. Une tâche sans responsable et sans date ne se fera pas.
6.Rôles et responsabilités
| Rôle | Nom | Responsabilité |
|---|---|---|
| Commanditaire | {{Nom}} | Valide le besoin et le budget, arbitre les demandes d’évolution |
| Maîtrise d’ouvrage | {{Nom}} | Porte le besoin, écrit les cas de test, prononce la recette |
| Maîtrise d’œuvre / prestataire | {{Nom}} | Développe, teste, documente, livre le code source |
| Exploitation | {{Nom}} | Environnements, mise en production, retour arrière, support |
Attribuez les responsabilités à des rôles, pas à des personnes : le plan survit alors à un changement d’équipe. Précisez qui décide, qui produit et qui doit seulement être informé.
7.Risques et mesures
| Risque | Impact | Probabilité | Mesure | Responsable |
|---|---|---|---|---|
| Le besoin change en cours de lot et la livraison glisse | élevé | élevée | Périmètre du lot 1 figé à la validation ; nouvelles demandes inscrites pour le lot suivant | {{Commanditaire}} |
| Recette contestée faute de critères | élevé | moyenne | Critères de recette écrits et contresignés avant le début des développements | {{Maîtrise d’ouvrage}} |
| Droits sur le code non cédés, changement de prestataire impossible | moyen | moyenne | Cession droit par droit et remise du code source prévues au contrat | {{Achats}} |
| Mise en production en échec | élevé | faible | Retour arrière répété, mise en production hors des heures de forte activité | {{Exploitation}} |
Ne retenez que les risques capables de faire dérailler le projet. Cotez impact et probabilité en élevé / moyen / faible, nommez la mesure et son responsable, et relisez le tableau à chaque point d’avancement.
8.Budget
| Poste | Budget prévu | Réalisé |
|---|---|---|
| Développement (interne ou prestataire) | {{Prévu}} | {{Réalisé}} |
| Licences, hébergement, outils | {{Prévu}} | {{Réalisé}} |
| Recette et formation | {{Prévu}} | {{Réalisé}} |
| Provision pour aléas | {{Prévu}} | {{Réalisé}} |
Estimez les grands postes de coût et prévoyez une provision pour aléas. Si le projet n’a pas de budget, gardez la section et inscrivez « sans objet » : les relecteurs s’attendent à la trouver.
9.Validation
Les deux signatures actent le périmètre, le calendrier et le budget avant le démarrage des travaux.
Exemple rempli pour une entreprise de maintenance d’ascenseurs de 140 salariés dotée d’un CSE, dont 85 techniciens itinérants, avec un prestataire au forfait.
1.Présentation du projet
| Nom du projet | Application mobile de gestion des interventions et des bons de passage |
|---|---|
| Commanditaire | Christophe Delorme, directeur général |
| Chef de projet | Amandine Roche, directrice des opérations (maîtrise d’ouvrage) |
| Date de début | 4 janvier 2027 |
| Date de fin visée | 1er octobre 2027 |
| Statut | Conforme au plan |
2.Objectifs et critères de réussite
- À partir du 1er octobre 2027, les 85 techniciens reçoivent leurs interventions et signent les bons de passage sur tablette
- Aucune anomalie bloquante ouverte à la recette ; bon de passage transmis au client en moins d’une heure après l’intervention
- Critère de réussite : trois mois après la mise en production, plus aucun bon papier ressaisi au siège
3.Périmètre
Dans le périmètre
- Planification des interventions, bon de passage signé sur tablette, photos, envoi au client
- Interface avec l’outil de facturation existant
- Recette, formation des techniciens et des planificateurs, passage en exploitation
- Cession à l’entreprise des droits sur le code et la documentation
Hors périmètre
- Géolocalisation des véhicules : écartée, elle n’est pas nécessaire au besoin exprimé
- Portail client en ligne : lot suivant, pas avant 2028
- Gestion des stocks de pièces des véhicules
- Reprise des bons papier antérieurs à 2026
4.Jalons et calendrier
| Jalon | Responsable | Date cible | Statut |
|---|---|---|---|
| Cahier des charges et critères de recette validés | Christophe Delorme | 26/02/2027 | En cours |
| Information et consultation du CSE terminées | Christophe Delorme | 26/03/2027 | Non démarré |
| Lot 1 livré complet sur l’environnement de recette | Atelier Logiciel Mercier | 11/06/2027 | Non démarré |
| Recette prononcée, procès-verbal signé | Amandine Roche | 02/07/2027 | Non démarré |
| Mise en production et passage en exploitation | Hugo Barre (informatique) | 01/10/2027 | Non démarré |
5.Tâches et lots de travaux
| Tâche | Responsable | Début | Échéance | Statut |
|---|---|---|---|---|
| Prévoir au contrat la cession droit par droit et la remise du code source | Christophe Delorme | 04/01/2027 | 29/01/2027 | Terminé |
| Écrire les critères de recette par fonction avec deux techniciens référents | Amandine Roche | 11/01/2027 | 26/02/2027 | En cours |
| Présenter le projet au CSE : données collectées, horodatage des interventions, ce qui n’est pas collecté | Christophe Delorme | 01/03/2027 | 26/03/2027 | À faire |
| Écrire les cas de test à partir de 30 interventions réelles | Amandine Roche | 01/03/2027 | 28/05/2027 | À faire |
| Répéter la procédure de retour arrière sur l’environnement de recette | Hugo Barre | 06/09/2027 | 24/09/2027 | À faire |
6.Rôles et responsabilités
| Rôle | Nom | Responsabilité |
|---|---|---|
| Commanditaire | Christophe Delorme | Valide le besoin et le budget, conduit la consultation du CSE |
| Maîtrise d’ouvrage | Amandine Roche | Porte le besoin, écrit les cas de test, prononce la recette |
| Prestataire | Atelier Logiciel Mercier (forfait) | Développe, teste, documente, livre le code source |
| Exploitation | Hugo Barre | Tablettes, environnements, mise en production, retour arrière |
| Techniciens référents | Paul Garnier et Nora Lahlou | Testent sur le terrain, forment leurs collègues |
7.Risques et mesures
| Risque | Impact | Probabilité | Mesure | Responsable |
|---|---|---|---|---|
| Les techniciens rejettent l’outil jugé trop lent sur le terrain | élevé | moyenne | Deux référents dans les tests dès le lot 1 ; objectif de moins de trois écrans par bon de passage | Amandine Roche |
| Couverture réseau absente dans les gaines et les sous-sols | élevé | élevée | Fonctionnement hors ligne exigé au cahier des charges, synchronisation à la sortie du bâtiment | Atelier Logiciel Mercier |
| Consultation du CSE plus longue que prévu | moyen | moyenne | Présentation dès mars, avant les développements des écrans d’horodatage | Christophe Delorme |
| Recette décalée par la charge de fin juin | moyen | moyenne | Créneaux de recette réservés en juin au planning des référents | Amandine Roche |
8.Budget
| Poste | Budget prévu | Réalisé |
|---|---|---|
| Développement au forfait | 118 000 € | 23 600 € |
| 85 tablettes renforcées et coques | 51 000 € | 0 € |
| Hébergement et licences pour 24 mois | 14 400 € | 0 € |
| Recette et formation des techniciens | 9 800 € | 0 € |
| Provision pour aléas | 12 000 € | 0 € |
9.Validation
Ce qu’un projet logiciel ajoute au plan de projet
Un projet informatique se distingue d’un autre projet sur trois points, qui ont leur place dans le plan : la recette conditionne le paiement et la levée des réserves, la cession des droits décide si vous pourrez un jour changer de prestataire, et la mise en production demande un chemin de retour éprouvé.
Le modèle ci-dessus fait donc de la recette, de la cession des droits et du retour arrière des jalons et des tâches à part entière. L’exemple rempli suit le développement d’une application de gestion des interventions pour les techniciens d’un mainteneur d’ascenseurs, par un prestataire externe.
Trois points à caler avant de démarrer
Ces trois points se tranchent dans le contrat ou avec les représentants du personnel, pas en cours de projet ; le plan doit néanmoins les faire apparaître, avec une date.
- Recette : critères, cas de test, personnes habilitées à signer le procès-verbal, seuil d’anomalies bloquantes.
- Droits : cession écrite des droits sur le code et la documentation au profit de l’entreprise, droit par droit (articles L113-9 et L131-3 du code de la propriété intellectuelle).
- CSE : information et consultation préalables lorsque l’outil permet un contrôle de l’activité des salariés ou introduit une nouvelle technologie (articles L2312-38 et L2312-8 du code du travail).
Sources
Code de la propriété intellectuelle, articles L113-9 et L131-3 ; code du travail, articles L2312-38 et L2312-8 — dans leur version en vigueur consultée sur legifrance.gouv.fr le 26 septembre 2026 ; le texte intégral de chaque article est accessible par les liens ci-dessous. Ce modèle ne constitue pas un conseil juridique : faites relire le contrat de développement avant signature.
Comment ça marche
- Lire le plan de projet informatique sur cette page, avec un exemple rempli chez un mainteneur d’ascenseurs.
- Télécharger le Word ou le PDF et inscrire la recette comme un jalon à part entière, avec ses critères.
- Régler la cession des droits sur le code avec le prestataire avant le démarrage des développements.
- Écrire et répéter la procédure de retour arrière avant la mise en production.
Questions fréquemment posées
Que contient un plan de projet informatique ?
Au-delà des objectifs, du périmètre et du budget, les points sur lesquels les projets logiciels déraillent : un cahier des charges priorisé, des lots au périmètre figé, les phases de test, une recette aux critères fixés à l’avance, la cession des droits sur le code et la documentation, le passage en exploitation et une procédure de retour arrière répétée.
Qu’est-ce que la recette ?
La recette est la phase où la maîtrise d’ouvrage vérifie que le logiciel livré est conforme au cahier des charges, à partir de cas de test écrits à l’avance ; elle se conclut par un procès-verbal de recette, avec ou sans réserves. Qui recette, sur quels critères, dans quel délai et avec quel seuil d’anomalies bloquantes : tout cela se fixe dans le contrat et dans le plan, pas le jour de la livraison.
À qui appartient le code développé ?
Sauf dispositions statutaires ou stipulations contraires, les droits patrimoniaux sur les logiciels et leur documentation créés par un ou plusieurs employés dans l’exercice de leurs fonctions ou d’après les instructions de leur employeur sont dévolus à l’employeur, seul habilité à les exercer (article L113-9 du code de la propriété intellectuelle). Pour un prestataire, prévoyez la cession dans le contrat : la transmission des droits de l’auteur suppose que chacun des droits cédés fasse l’objet d’une mention distincte et que le domaine d’exploitation soit délimité quant à son étendue et à sa destination, quant au lieu et quant à la durée (article L131-3).
Le CSE doit-il être consulté ?
Dans une entreprise d’au moins cinquante salariés, si le logiciel est utilisé en interne, vérifiez deux textes. Le comité est informé et consulté, préalablement à la décision de mise en œuvre, sur les moyens ou les techniques permettant un contrôle de l’activité des salariés, et il est informé, préalablement à leur introduction, des traitements automatisés de gestion du personnel (article L2312-38 du code du travail). Il est aussi informé et consulté sur l’introduction de nouvelles technologies (article L2312-8).
Faut-il prévoir un retour arrière ?
Toujours, et le tester. Écrivez qui décide du retour arrière, jusqu’à quand après la mise en production, quelles opérations techniques sont nécessaires et comment les utilisateurs sont prévenus. Répétez-le une fois sur l’environnement de recette : c’est la seule façon de savoir s’il prend vingt minutes ou une journée.