Pourquoi votre projet logiciel est en retard (et que faire à ce sujet)

Le rapport CHAOS 2024 du Standish Group a révélé que66 % des projets logiciels dépassent leur calendrier ou leur budget. Une personne sur cinq est purement et simplement annulée. Ces chiffres sont restés obstinément constants pendant plus d’une décennie.

Les causes ne sont pas mystérieuses. Ils se répètent dans tous les secteurs, tailles d’entreprises et piles technologiques. Après avoir expédié des dizaines de projets clients chez Savi, six modèles représentent la grande majorité des retards que nous constatons. Tous sont évitables. Voici comment les repérer et que faire à la place.

1. La dérive du périmètre tue plus de projets que le mauvais code

La dérive du périmètre est la raison la plus courante pour laquelle les projets logiciels sont en retard. Cela commence petit. Une partie prenante dit "pendant qu'on y est, pouvons-nous aussi ajouter..." lors d'un stand-up. Le Premier ministre hoche la tête. L'ingénieur ajoute une tâche. Multipliez cela par trois demandes par semaine sur huit semaines, et votre projet initial de 6 semaines est désormais un projet de 14 semaines sans fin en vue.

Voici les calculs qui rendent la dérive de la portée si destructrice :un changement d'exigences au cours de la semaine 1 coûte environ 1 heure de temps d'ingénierie. Le même changement au cours de la semaine 8 coûte 10 fois plus. À la semaine 8, la base de code comporte des dépendances construites sur la conception originale. Changer de direction signifie refactoriser le code fonctionnel, mettre à jour les tests, revérifier les intégrations et retester les fonctionnalités que vous avez déjà approuvées.

L'IBM Systems Sciences Institute a publié des données montrant que les défauts détectés lors de la phase de maintenance coûtent 100 fois plus cher à corriger que les défauts détectés lors de la phase de conception. Les modifications des exigences suivent la même courbe de coûts.

Que faire à la place :Rédigez un document d'exigences produit (PRD) avant d'écrire un code. Répertoriez chaque fonctionnalité, chaque flux d'utilisateur et chaque point de terminaison d'API. Obtenez l’approbation de toutes les parties prenantes. Traitez ensuite le PRD comme un contrat. Les nouvelles idées vont dans un « backlog v2 », et non dans le sprint actuel. Chez Savi, nous consacrons 1 à 2 semaines à la définition des exigences avant le début du développement. Cet investissement de 1 500 $ dans la planification permet d'économiser plus de 10 000 $ en retouche à mi-projet.

2. Les couches de communication ajoutent des semaines, pas de la clarté

Imaginez une configuration d'agence typique : vous expliquez votre demande de fonctionnalité à un responsable de compte. Le responsable de compte rédige un ticket et l'attribue à un chef de projet. Le chef de projet la traduit en spécification technique et l'envoie au responsable technique. Le responsable technique l'attribue à un développeur. Le développeur a une question, donc toute la chaîne s'inverse.

Chaque transfert dans cette chaîne introduit deux problèmes. Premièrement, la perte d’informations. Votre demande initiale était nuancée ; au moment où il parvient au développeur, il a été paraphrasé trois fois. Deuxièmement, la latence. Chaque transfert ajoute 4 à 24 heures de temps d'attente. Une question qui pourrait être résolue en 5 minutes par appel prend 3 jours pour parcourir la chaîne de communication.

Une étude du Project Management Institute a révélé que56 % du budget du projet à risque est dû à une mauvaise communication. Sur un projet de 50 000 $, cela représente 28 000 $ exposés à un gaspillage de mauvaise communication.

Que faire à la place :Parlez directement à la personne qui écrit votre code. Chez Savi, chaque client dispose d'un canal Slack direct avec son ingénieur senior affecté. Aucun gestionnaire de compte ne relaye les messages. Aucune exigence d’interprétation pour les PM. Vous décrivez ce dont vous avez besoin ; l'ingénieur pose des questions de clarification en temps réel ; la fonctionnalité est construite correctement du premier coup. Ce seul changement élimine 30 à 40 % des allers-retours qui gonflent les délais.

3. Une mauvaise composition d’équipe brûle le budget lors des transferts

De nombreuses agences emploient dans leurs projets 4 à 6 développeurs : deux frontend, deux backend, un ingénieur QA et une personne DevOps. Cela semble productif. En pratique, cela crée une taxe de coordination qui absorbe 30 à 40 % du budget total.

L'équipe frontend crée un composant de formulaire et a besoin d'un point de terminaison API. Ils déposent un ticket pour l’équipe backend. L'équipe backend est à mi-sprint sur une fonctionnalité différente. Trois jours passent. Le développeur frontend passe à une autre tâche. Lorsque le point de terminaison est prêt, le développeur frontend doit revenir en arrière. Le point de terminaison renvoie les données sous une forme différente de celle attendue. Un autre aller-retour commence.

L'embauche d'un trop grand nombre de développeurs juniors crée le même problème d'une manière différente. Les juniors écrivent du code qui fonctionne sur leur machine locale mais échoue lors de la mise en scène. Un ingénieur senior passe 3 heures à déboguer le problème de déploiement d'un junior au lieu de créer des fonctionnalités. La vitesse effective de l'équipe chute à 40 à 50 % de sa capacité théorique.

Que faire à la place :Effectuer les projets avec 1 à 2 ingénieurs full-stack senior qui possèdent l'intégralité de la base de code. Un ingénieur qui crée l'API, écrit le frontend, configure la base de données et déploie l'application n'a aucune surcharge de transfert. Chez Savi, c'est notre valeur par défaut. Un seul ingénieur senior expédiant un projet de 20 000 $ en 5 semaines surpasse une équipe de quatre juniors expédiant le même projet en 12 semaines avec plus de bugs et un coût total plus élevé.

4. Aucun critère « terminé » défini pour les fonctionnalités

"Créer le tableau de bord utilisateur" n'est pas une spécification de fonctionnalité. C'est un démarreur de conversation. Sans critères d'acceptation explicites, les ingénieurs font des hypothèses. Parfois, ces hypothèses correspondent à ce que souhaitait le client. Souvent, ce n’est pas le cas.

Le résultat : l'ingénieur construit un tableau de bord avec trois graphiques et un tableau de données. Le client attendait cinq graphiques, un filtre de plage de dates, un bouton d'exportation CSV et une vue comparative. L'ingénieur le reconstruit. Le client donne son avis sur la reconstruction. Une fonctionnalité qui aurait dû prendre 3 jours en prend 10.

Ce modèle est si courant qu’il porte un nom en gestion de projet :le piège du "90% fait". Une fonctionnalité reste « presque terminée » pendant des semaines parce que personne n’a défini à quoi ressemble « fini ». Les ingénieurs continuent de peaufiner. Les clients continuent de demander des changements. Le projet saigne le temps.

Que faire à la place :Rédigez des critères d'acceptation pour chaque fonctionnalité avant le début du développement. Utilisez ce format : "Cette fonctionnalité est effectuée lorsque [condition spécifique et testable]." Par exemple : "Le tableau de bord est terminé lorsqu'il affiche les revenus, les commandes et le taux de conversion pour la plage de dates sélectionnée, avec un bouton d'exportation CSV qui télécharge toutes les données visibles." L'ingénieur sait exactement quoi construire. Le client sait exactement à quoi s'attendre. Personne ne se demande si c’est « fait ».

5. Sous-estimer la complexité de l’intégration

"Nous devons intégrer Stripe" semble être une tâche d'une journée. En réalité, une intégration Stripe de niveau production comprend : la création d'intentions de paiement, la gestion des webhooks pour les événements asynchrones (paiement réussi, échec du paiement, abonnement annulé, litige ouvert), des clés d'idempotence pour éviter les frais en double, une logique de nouvelle tentative pour les webhooks ayant échoué, un portail client pour la gestion des abonnements et des états d'erreur appropriés dans l'interface utilisateur pour chaque mode d'échec.

Cette « tâche d'une journée » prend 3 à 5 jours pour un ingénieur senior et 7 à 10 jours pour un junior. Multipliez cette sous-estimation par 3 à 4 intégrations (passerelle de paiement, fournisseur de messagerie, analyses, KYC) et vous avez ajouté 2 à 4 semaines à un projet pour lequel personne n'avait prévu de budget.

La qualité des API tierces varie énormément. Stripe dispose d'une excellente documentation et d'environnements sandbox. De nombreuses API spécifiques à un secteur (banque, logistique, gouvernement) ont des documents incomplets, des bacs à sable peu fiables et des équipes d'assistance qui répondent dans les 48 à 72 heures. Chaque API mal documentée ajoute 2 à 3 fois le temps d'intégration estimé.

Que faire à la place :Auditez chaque intégration pendant la phase des exigences. Pour chaque service tiers, répondez à trois questions : dispose-t-il d'un environnement sandbox ? Dans quelle mesure la documentation est-elle complète ? Quel est le délai de réponse du support ? Estimez ensuite le temps d'intégration à 3 fois ce qui semble raisonnable. Créez une preuve de concept pour l’intégration la plus risquée avant de vous engager sur un calendrier complet du projet. Chez Savi, nous prototypons les intégrations à haut risque au cours de la première semaine et ajustons le calendrier en fonction de ce que nous trouvons, et non de ce que promet la page marketing de l'API.

6. Les lancements de Big Bang créent des échecs de Big Bang

L'approche « tout construire, lancer une fois » est la stratégie de livraison la plus risquée en matière de développement logiciel. Les équipes passent 3 à 6 mois à construire en isolement. Personne en dehors de l’équipe de développement ne voit le produit. Le jour du lancement, des dizaines de fonctionnalités ont été mises en production simultanément. Composé de bogues. Les utilisateurs rencontrent des flux interrompus. L'équipe passe les 2 semaines suivantes en mode lutte contre les incendies au lieu d'itérer.

Les lancements big bang masquent également les dérapages de calendrier. Lorsque l’ensemble du projet constitue un livrable monolithique, il est impossible de mesurer les progrès avec précision. Une équipe peut signaler « 80 % terminé » pendant 6 semaines consécutives, car les derniers 20 % contiennent les problèmes les plus difficiles : tests d'intégration, cas extrêmes, configuration de déploiement et migration de données.

Que faire à la place :Expédiez progressivement. Divisez le projet en étapes d'une à deux semaines, chacune produisant une fonctionnalité fonctionnelle et déployable. Chez Savi, nous organisons des démos hebdomadaires où le client voit un logiciel fonctionnel, clique sur des flux réels et donne son avis sur un environnement de mise en scène en direct. Si quelque chose ne va pas, nous le détectons au cours de la semaine 2, pas de la semaine 12.

La livraison incrémentielle vous offre également une trappe de secours. Si le budget ou les priorités changent à la semaine 4, vous disposez d'un produit fonctionnel avec quatre semaines de fonctionnalités déployées et utilisables. Avec une livraison big bang, vous n’avez rien d’utilisable jusqu’à ce que l’ensemble du projet soit livré.

Une liste de contrôle avant de démarrer votre prochain projet

Ces six problèmes ne sont pas une fatalité. Ce sont des échecs de processus, et les échecs de processus ont des solutions de processus. Avant le lancement de votre prochain projet, vérifiez ces six conditions :

• Les exigences sont écrites et signées.Chaque fonctionnalité a des critères d'acceptation. Les parties prenantes se sont mises d’accord sur la portée par écrit, et non lors d’un appel que personne n’a documenté.
• Vous pouvez parler à l’ingénieur qui construit votre produit.Aucun intermédiaire ne traduit vos exigences. Accès direct via Slack, e-mail ou appel vidéo.
• L'équipe est petite et senior.1 à 2 ingénieurs full-stack qui possèdent l'intégralité de la base de code. Il ne s'agit pas d'une équipe de 6 personnes avec des transferts entre le frontend, le backend, l'assurance qualité et DevOps.
• Chaque fonctionnalité a une définition « terminé ».Conditions testables et spécifiques. Non pas « créer le tableau de bord » mais « afficher les revenus, les commandes et le taux de conversion avec une exportation CSV ».
• Les intégrations sont prototypées dès le début.La connexion tierce la plus risquée est testée au cours de la semaine 1, et non de la semaine 8.
• Vous voyez des logiciels fonctionnels chaque semaine.Démonstrations hebdomadaires sur un environnement de staging. De vrais clics, de vraies données, de vraies boucles de rétroaction.

Les projets qui cochent les six cases sont expédiés à temps. Les projets qui en sautent ne serait-ce qu'un seul sont en retard. La corrélation est aussi cohérente.

Questions fréquemment posées