Un diagramme PERT sert à faire apparaître ce que beaucoup de plannings cachent encore : l’ordre réel des tâches, leurs dépendances et le point où un retard devient vraiment dangereux. Pour un projet numérique, une refonte de portail ou un lancement de service, c’est souvent la différence entre un calendrier approximatif et un pilotage sérieux. Je vais prendre un exemple concret, montrer comment lire le réseau, puis expliquer comment en tirer un planning exploitable.
Les points à retenir avant de tracer le réseau
- Le PERT est un réseau de dépendances, pas une simple liste de tâches.
- Il devient particulièrement utile quand les durées sont incertaines et que plusieurs équipes avancent en parallèle.
- La logique repose sur trois estimations de durée : optimiste, probable et pessimiste.
- Le chemin critique fixe la date de fin du projet ; les tâches dessus n’ont pas de marge.
- La marge totale et la marge libre servent à absorber les aléas sans casser la date de livraison.
- En pratique, je l’utilise souvent avec un diagramme de Gantt, pas à sa place.
Pourquoi un réseau PERT reste utile quand les délais sont incertains
Je réserve le PERT aux projets où l’enchaînement des tâches compte plus que la simple vue calendrier. Dès qu’un travail dépend d’une validation métier, d’une équipe technique ou d’un fournisseur externe, le réseau PERT devient très lisible : il montre ce qui bloque quoi, et pas seulement quand une tâche est censée commencer.
Son intérêt principal est simple : il oblige à penser en séquences et en interdépendances. Dans un projet SI, on évite ainsi de croire qu’une tâche peut avancer alors qu’une autre n’est pas terminée. C’est aussi ce qui en fait un outil utile en phase de cadrage, avant que le planning ne se transforme en suite de dates figées.
En revanche, je ne le conseille pas comme unique support de suivi pour un projet très linéaire ou très stable. Si les tâches sont peu nombreuses, peu incertaines et presque indépendantes, un Gantt bien tenu peut suffire. C’est précisément pour cela qu’un exemple concret vaut mieux qu’une définition abstraite.
Un exemple concret pour un projet numérique de bout en bout
Prenons un cas réaliste : la mise en ligne d’un portail client. Le projet est assez simple pour rester lisible, mais suffisamment structuré pour montrer la logique PERT. J’utilise ici des durées attendues calculées à partir de trois estimations, parce que c’est là que la méthode prend tout son sens.
| Tâche | Dépendance(s) | Optimiste | Probable | Pessimiste | Durée attendue |
|---|---|---|---|---|---|
| A. Cadrage du besoin | Aucune | 1 j | 2 j | 3 j | 2,0 j |
| B. Ateliers UX | A | 3 j | 4 j | 6 j | 4,2 j |
| C. Architecture technique | A | 2 j | 3 j | 5 j | 3,2 j |
| D. Développement front-end | B | 4 j | 6 j | 8 j | 6,0 j |
| E. Développement back-end | C | 6 j | 8 j | 12 j | 8,3 j |
| F. Tests d’intégration | D, E | 2 j | 3 j | 5 j | 3,2 j |
| G. Préparation du déploiement | F | 1 j | 2 j | 3 j | 2,0 j |
| H. Mise en production | G | 0,5 j | 1 j | 2 j | 1,2 j |
Avec cette trame, le chemin critique passe par A → C → E → F → G → H. Autrement dit, le délai du projet est dicté par la chaîne la plus longue, ici environ 19,9 jours. Je retiens surtout un point : ce n’est pas la durée moyenne de chaque tâche qui compte isolément, mais la combinaison des dépendances.
Pour E, par exemple, le calcul donne (6 + 4×8 + 12) ÷ 6 = 8,3 jours. Cette logique évite de bâtir un planning sur une estimation trop optimiste. Dans la pratique, c’est souvent là que les équipes se trompent : elles confondent le meilleur scénario avec la date engageante.
Ce type d’exemple montre bien pourquoi le PERT est utile au démarrage d’un projet numérique : il force à poser les bonnes questions avant de lancer l’exécution. Une fois le réseau lisible, il reste à le construire proprement.
Construire le réseau sans perdre la logique des dépendances
Quand je construis un PERT, je procède toujours dans le même ordre. Le but n’est pas de dessiner vite, mais de dessiner juste. Un réseau mal posé fausse les marges, et derrière, c’est tout le pilotage qui se dérègle.
- Lister les tâches à un niveau de détail utile, ni trop vague ni trop fin. Dans un projet IT, je pars souvent du WBS pour éviter les oublis.
- Identifier les dépendances réelles. Une tâche peut-elle démarrer avant une validation, une intégration ou une livraison externe ? Si la réponse est non, elle doit apparaître dans le réseau.
- Estimer les durées à trois points. La formule classique est E = (O + 4M + P) / 6. Le terme important n’est pas la formule elle-même, mais le fait d’intégrer l’incertitude.
- Relier les tâches avec des flèches ou des nœuds, selon la convention utilisée par l’outil. L’important est de garder une logique de séquencement claire.
- Calculer les dates au plus tôt et au plus tard. C’est ce double passage qui permet d’identifier les marges et le chemin critique.
Je recommande aussi de vérifier le réseau avec les parties prenantes avant de figer le planning. Un chef de projet peut très bien avoir un dessin cohérent sur le papier et une dépendance manquante dans la vraie vie. C’est exactement le genre d’erreur qui coûte cher plus tard, quand la marge disparaît sans prévenir.
Une fois le réseau construit, la vraie valeur vient de sa lecture. C’est là que les marges deviennent utiles et que le projet cesse d’être un simple tableau de tâches.
Lire les marges et repérer le chemin critique
Deux notions comptent vraiment ici. La marge totale indique le retard qu’une tâche peut absorber sans décaler la fin du projet. La marge libre indique le retard possible sans impacter le démarrage de la tâche suivante. En gestion de projet, cette nuance évite bien des confusions.Dans l’exemple du portail client, les tâches B et D disposent encore d’environ 1,3 jour de marge totale. Le reste de la chaîne est critique et ne supporte pas de glissement si l’on veut tenir la date finale. Autrement dit, un léger retard sur l’architecture ou les ateliers UX peut être absorbé, mais un dérapage sur le back-end ou les tests se répercute directement sur la livraison.
| Tâche | Rôle dans le projet | Marge totale approximative |
|---|---|---|
| A | Départ du réseau | 0 j |
| B | Non critique | 1,3 j |
| C | Critique | 0 j |
| D | Non critique | 1,3 j |
| E | Critique | 0 j |
| F | Critique | 0 j |
| G | Critique | 0 j |
| H | Critique | 0 j |
Je trouve cette lecture très utile pour arbitrer les ressources. Si une urgence surgit, je sais où un petit glissement est acceptable et où il ne l’est pas. C’est précisément ce qui différencie un bon PERT d’un schéma décoratif.
À ce stade, une question revient presque toujours : faut-il encore un Gantt, ou le PERT suffit-il à lui seul ? C’est là que la comparaison devient utile.
PERT et Gantt ne servent pas au même moment
Je ne les oppose pas, je les place dans la bonne séquence. Le PERT sert d’abord à penser le projet et à clarifier les dépendances. Le Gantt sert ensuite à suivre l’exécution, les dates, les jalons et l’avancement visible par l’équipe ou le sponsor.
| Critère | PERT | Gantt |
|---|---|---|
| Usage principal | Planifier les dépendances et estimer la durée | Suivre les dates et l’avancement |
| Lecture | Réseau de tâches | Calendrier horizontal |
| Meilleur moment | Cadrage et lancement | Pilotage opérationnel |
| Point fort | Vision des dépendances et du chemin critique | Lisibilité immédiate pour l’équipe |
| Limite | Peut devenir lourd si le projet change sans arrêt | Montre moins bien la logique des interdépendances |
Dans un projet IT, je les utilise souvent ensemble : le PERT pour sécuriser l’ordonnancement, puis le Gantt pour tenir le rythme au quotidien. Si tout ce que vous cherchez est une vue simple des échéances, le Gantt peut suffire. Si vous devez arbitrer des dépendances complexes, le PERT apporte une profondeur que le Gantt ne donne pas aussi bien.
Cette complémentarité explique aussi les limites de la méthode. Un PERT utile n’est pas un PERT parfait, c’est un PERT maintenu à jour.
Ce que je retiens pour l’utiliser sans alourdir le pilotage
Le vrai intérêt du PERT n’est pas le dessin lui-même, mais la discipline qu’il impose au démarrage du projet. Il oblige à poser les dépendances, à chiffrer l’incertitude et à accepter qu’une date de fin sérieuse repose rarement sur une seule estimation. Pour un projet numérique, c’est souvent un gain de clarté immédiat.
- Utilisez-le au bon moment : surtout en cadrage, quand il faut comprendre la structure du travail.
- Mettez-le à jour dès qu’une dépendance change ou qu’un retard apparaît.
- Ne confondez pas estimation et engagement : une durée attendue n’est pas une promesse.
- Gardez le réseau lisible : si le schéma devient illisible, il perd sa valeur de pilotage.
Pour un projet de gestion de projet ou de transformation numérique, je conseille presque toujours d’associer un WBS propre, un réseau PERT pour la logique de dépendances et un Gantt pour l’exécution. C’est cet assemblage, plus que l’outil lui-même, qui permet de tenir une échéance sans naviguer à vue.
