- Un diagramme de Gantt construit dans Excel est un dessin, pas un modèle : déplacer une tâche ne déplace jamais celles qui en dépendent.
- C’est cette absence de dépendance entre tâches qui explique la plupart des plannings Excel abandonnés au bout de trois semaines, pas le manque de fonctions.
- Trois colonnes suffisent à rendre un suivi utilisable : la date de fin prévue, le responsable, et l’état choisi dans une liste fermée.
- Excel reste le bon outil tant qu’une seule personne tient le planning. Le partage en écriture est la vraie limite, pas la taille du projet.
Ce qu’un planning Excel ne sait pas faire
Les modèles de gestion de projet pour Excel se comptent par dizaines, tous construits autour d’un diagramme de Gantt en barres colorées. Ils fonctionnent le jour où on les remplit. Le problème apparaît à la première replanification.
Un logiciel de gestion de projet sait qu’une tâche en suit une autre. Repousser la première de trois jours repousse automatiquement toutes les suivantes, et la date de fin du projet se recalcule seule. Excel ne connaît pas cette notion. Les barres du Gantt sont de la mise en forme conditionnelle appliquée à des dates saisies à la main : elles ne savent rien les unes des autres.
La conséquence est brutale et silencieuse. Un retard sur une tâche du début oblige à corriger manuellement chaque date en aval, sur toutes les lignes concernées. Personne ne le fait plus de deux ou trois fois, et le planning cesse d’être à jour sans que rien ne signale qu’il a décroché.
Deux réponses tiennent, et aucune ne consiste à faire semblant. La première est de renoncer aux dates de début et de fin pour les tâches intermédiaires, et de ne dater que les jalons, ceux qui ont une échéance réelle vis-à-vis de quelqu’un. Une dizaine de dates tenues à jour valent mieux que cinquante dates fausses.
La seconde est de bloquer un moment fixe, une fois par semaine, pour repasser les dates en une seule fois plutôt qu’au fil de l’eau. La correction manuelle n’est pas le problème ; ce qui casse un planning, c’est de la faire à moitié.
La structure minimale d’un suivi qui sert
Avant les couleurs et les barres, un fichier de projet a besoin de colonnes justes. Trois d’entre elles font l’essentiel du travail. C’est la même exigence que pour un fichier client : une ligne par élément, une information par colonne.
L’état choisi dans une liste déroulante fermée mérite qu’on s’y arrête. Laissé en saisie libre, il produit en trois semaines « en cours », « En cours », « encours » et « en cour », que ni un filtre ni un décompte ne regrouperont jamais. La liste se pose par la validation des données, dans l’onglet Données, et elle prend une minute.
Le responsable désigné nommément est le second point sur lequel on transige trop facilement. Une tâche attribuée à « l’équipe technique » n’est attribuée à personne, et c’est toujours celle-là qui n’avance pas.
Les formules qui valent la peine, et celles qui coûtent cher
Un suivi de projet n’a besoin que de deux ou trois formules. Au-delà, le fichier devient une petite application que personne d’autre que son auteur ne saura réparer.
| Ce qui sert vraiment | À quoi ça répond |
|---|---|
SERIE.JOUR.OUVRE |
Une date de fin qui saute les week-ends et les jours fériés |
NB.SI |
Le compte des tâches par état, pour un mini tableau de bord |
| La mise en forme conditionnelle | Colorer seul ce qui est en retard, sans y penser |
Ce qu’il vaut mieux éviter : les formules qui recalculent des dates en cascade pour imiter la dépendance entre tâches. Elles existent, elles fonctionnent sur trois lignes, et elles se cassent à la première insertion de ligne au milieu du tableau. Réparer une chaîne de formules dont on a perdu le fil coûte plus de temps que de tenir les dates à la main.
Même prudence avec les macros trouvées en ligne : elles obligent le fichier à être enregistré dans un format particulier, déclenchent des avertissements de sécurité à chaque ouverture, et se transmettent mal d’un poste à l’autre.
Le retard qui ne se voit pas
Un planning Excel affiche fidèlement ce qu’on lui a saisi, ce qui est exactement son défaut : rien ne signale que la saisie a cessé d’être à jour.
Une colonne de dernière mise à jour, remplie à la main à chaque passage, règle le problème pour un coût nul. Un coup d’œil suffit alors à distinguer un projet calme d’un projet abandonné, deux situations qui donnent le même tableau vert.
La mise en forme conditionnelle rend le même service sur les échéances : une règle qui compare la date de fin prévue à la date du jour colore seule les lignes dépassées. Tout dépend ensuite de la fréquence à laquelle quelqu’un ouvre réellement le fichier, et c’est une question d’organisation, pas de tableur.
Le moment où il faut changer d’outil
Il arrive plus tôt qu’on ne croit, et pour une raison unique : plusieurs personnes doivent écrire dans le fichier. Un classeur partagé sur un dossier réseau produit alors des versions concurrentes, et l’édition simultanée en ligne règle le conflit technique sans régler le fond, puisque deux personnes peuvent toujours saisir deux dates contradictoires.
Tant que le planning a un seul propriétaire qui centralise les mises à jour, Excel tient très bien, y compris sur un projet de plusieurs mois. Un chantier à cinquante tâches suivi par une personne est parfaitement à sa place dans un tableur ; le même chantier suivi par quatre personnes ne l’est plus, même à vingt tâches.
Le nombre de tâches, lui, n’entre presque pas en ligne de compte. C’est le critère qu’on met en avant, et c’est rarement celui qui décide.
Vérifier que le fichier tient encore
Trois contrôles, à refaire de temps en temps sur un projet qui dure.
- Triez par date de fin prévue. Un ordre qui n’a rien de chronologique révèle des dates saisies en texte, et rend tout le reste faux.
- Filtrez sur l’état « en cours » et comptez. Si le nombre obtenu ne correspond pas à ce que vous saviez du projet, la liste déroulante n’a pas été respectée quelque part.
- Repérez la tâche la plus ancienne toujours ouverte. Sur un planning à jour, il y a une explication ; sur un planning décroché, il n’y en a pas.
Un fichier qui échoue à ces trois contrôles ne demande pas un meilleur modèle. Il demande qu’on décide qui le tient, et à quelle fréquence.
Quinze ans de support informatique en entreprise, du helpdesk à l'administration système. J'ai traité des milliers de tickets et constaté que les mêmes problèmes revenaient en boucle. J'écris ici les réponses que je donnais au téléphone.