« Vous pensez que ça prend combien de temps ? » C’est souvent la deuxième question, juste après le prix. Et la réponse honnête est décevante : personne ne peut le dire sérieusement avant d’avoir regardé vos données et vos connexions.
Ce qu’on peut faire en revanche, c’est nommer ce qui fait varier le résultat. Parce que dans les projets qui glissent, ce n’est presque jamais le développement qui a pris plus longtemps que prévu.
Ce qui prend du temps, dans l’ordre inverse de ce qu’on croit
Sur un projet de PME, le temps se répartit rarement comme dans l’imaginaire du commanditaire. L’écriture du code est la partie la plus visible, la plus facile à estimer, et souvent pas la plus longue.
Voici les quatre postes qui décident réellement du calendrier.
1. Le temps de décision chez vous
C’est le premier facteur, et il n’apparaît dans aucun devis.
Un projet avance à la vitesse à laquelle les questions reçoivent des réponses. Une question posée un mardi et tranchée trois semaines plus tard, parce que la personne qui sait était en déplacement puis en congés, coûte trois semaines. Multipliez par le nombre d’arbitrages d’un projet et vous avez souvent le principal écart entre un projet de trois mois et le même projet en sept mois.
Ce n’est pas une critique du client. C’est une contrainte à traiter comme les autres : nommer une personne qui décide, avec du temps réellement réservé, et une règle explicite pour les cas où elle est absente. Un projet sans référent interne disponible dérape quel que soit le prestataire. C’est même le meilleur prédicteur que je connaisse.
2. La reprise de données
Le poste le plus systématiquement sous-estimé, par les deux parties.
Les données existent, elles paraissent propres, et elles ne le sont jamais. Des doublons qu’on n’avait pas vus parce que l’orthographe diffère. Des champs remplis avec autre chose que ce qu’ils devaient contenir, parce qu’il fallait bien noter l’information quelque part. Des historiques incomplets sur une période dont personne ne se souvenait.
Rien de tout cela n’est un scandale. C’est l’état normal d’un jeu de données de dix ans. Mais chaque anomalie découverte demande une décision, et chaque décision revient au point 1.
La contre-mesure est de commencer la reprise tôt, sur un échantillon, avant que le reste soit prêt. Ce n’est pas naturel, parce que la reprise paraît être une tâche de fin. C’est précisément pour ça qu’elle fait glisser les projets.
3. La recette
Vérifier que ce qui est livré correspond à ce qui était dû prend du temps, et ce temps est celui de vos équipes, pas du prestataire.
Un projet dont la recette est prévue « sur deux semaines » alors que les personnes qui doivent tester ont un métier à plein temps ne sera pas recetté en deux semaines. Il sera recetté en cinq, ou il sera validé sans avoir été testé, ce qui est pire : les défauts apparaîtront en production, quand ils coûtent le plus cher à corriger.
Deux choses aident. Écrire les critères de recette dès le cahier des charges, pour que la recette soit une vérification et non une découverte. Et réserver le temps des testeurs dans leur planning, pas dans le planning du projet.
4. Le passage en production
La bascule elle-même est rarement longue. Ce qui l’est, c’est ce qui l’entoure.
Il faut une fenêtre où l’interruption est acceptable, un plan de retour arrière écrit avant de commencer, et une période où l’ancien et le nouveau système coexistent. Cette coexistence est la phase la plus inconfortable d’un projet : deux outils à maintenir, deux jeux de procédures, et une équipe qui doit savoir lequel fait foi.
Sur ce point, l’expérience apprend une chose contre-intuitive : découper la bascule en vagues rallonge le calendrier affiché et raccourcit le temps réel jusqu’à la stabilité. Une bascule unique est plus courte sur le papier et plus longue quand elle rate.
Comment lire un délai dans un devis
Trois réflexes, qui prennent dix minutes.
Cherchez la reprise de données. Si elle n’a pas sa propre ligne avec sa propre durée, elle a été estimée à la légère ou pas du tout.
Cherchez la recette. Si elle apparaît comme une durée sans mention de qui teste, elle n’a pas été prévue comme une charge pour vos équipes. Elle le sera.
Cherchez ce que le délai exclut. Comparer deux devis en regardant les durées annoncées n’a aucun sens si l’un inclut la formation et l’autre non. Comparez d’abord les exclusions. C’est presque toujours là que se trouve l’explication de l’écart.
Le seul délai sur lequel on s’engage
Nous nous engageons contractuellement sur les délais du périmètre cadré, avec des contreparties prévues au contrat en cas de manquement. C’est possible pour une seule raison : le cadrage a eu lieu avant, et il a regardé les données réelles. Sans cette étape, un engagement de délai serait une formule commerciale.
C’est aussi pourquoi nous facturons le cadrage plutôt que de l’offrir. Un cadrage gratuit est un cadrage rapide, et un cadrage rapide produit exactement les estimations qui glissent ensuite. La feuille de route stratégique existe pour ça, et son coût est déduit si une mission suit dans les trente jours.
Pour aller plus loin
- Combien coûte un logiciel sur-mesure : les cinq postes qui font exploser une facture
- Recette d’un logiciel : le plan de tests qui évite la mise en production ratée : comment la recette cesse d’être une découverte
- Retour arrière d’une mise en production à 23h : pourquoi le plan de repli s’écrit avant
- Modèle de cahier des charges à télécharger : la section reprise de données déjà cadrée
- Feuille de route stratégique : le cadrage qui rend un engagement de délai possible
- Un chantier n’attend pas la fin d’un projet informatique : quand le calendrier est une donnée de conception