Il existe peu de dépenses aussi difficiles à surveiller qu'un développement logiciel. Vous réglez les factures au fil des mois, vous recevez des comptes rendus qui se ressemblent tous, et rien de ce que vous avez sous les yeux ne permet de vérifier si le chantier avance vraiment ou s'il tourne sur lui-même. La bonne nouvelle, c'est que juger un projet ne demande aucune compétence technique : cela demande quelques questions précises et une arithmétique du même ordre que celle que vous faites déjà pour votre stock ou votre trésorerie.
Pourquoi personne ne vous répond franchement sur l'avancement
La scène se rejoue dans presque toutes les entreprises qui font développer un outil. Depuis trois mois, le point hebdomadaire annonce quatre-vingts pour cent, les factures, elles, arrivent avec une régularité irréprochable, et vous n'avez toujours aucun moyen de savoir si ces quatre-vingts pour cent existent ailleurs que dans une phrase. Vous n'insistez pas, par crainte de poser une question naïve, et l'équipe en face ne ment pas non plus : elle mesure ce qu'elle voit, c'est-à-dire son propre travail, ce qui n'est pas du tout la même chose que ce que vous pourriez utiliser aujourd'hui.
Le malentendu vient de deux notions qui se ressemblent beaucoup vues de l'extérieur. Il y a l'activité : des réunions, des maquettes, des écrans en cours, des gens visiblement occupés du matin au soir. Et il y a l'avancement : quelque chose qu'un vrai client pourrait utiliser aujourd'hui, tel quel, sans qu'on lui explique à l'avance ce qu'il ne faut surtout pas cliquer. L'activité se raconte et se facture, alors que l'avancement se teste, et une seule des deux vaut de l'argent. C'est presque toujours la seconde que les comptes rendus décrivent le moins bien.
Autant désamorcer l'angoisse tout de suite : la plupart des projets dérivent à un moment ou à un autre, y compris les nôtres, et une dérive se rattrape très bien quand on la voit venir. Ce qui coûte cher, ce n'est jamais le retard en lui-même, c'est de l'apprendre tard, lorsqu'il ne reste plus assez de budget ni de calendrier pour choisir autre chose que payer davantage. Un projet en retard repéré au deuxième mois se renégocie tranquillement, tandis que le même projet découvert au huitième mois se subit.
À la fin de cet article, vous pourrez porter un jugement sur votre propre chantier sans savoir ce qu'est une base de données, à partir de questions qu'une équipe honnête accueillera avec soulagement, parce qu'elles lui donnent enfin l'occasion de montrer ce qu'elle a réellement produit.
La seule preuve qui compte, c'est un logiciel que vous cliquez vous-même
Commençons par un mot de vocabulaire, puisque tout repose dessus. Il existe presque toujours une copie privée du système, réservée à l'équipe et à vous, où le travail est déposé et contrôlé avant qu'un seul client ne le voie. Selon les entreprises, on l'appelle site de test, préproduction ou recette, et le nom importe peu. Ce qui importe, c'est qu'elle existe et que vous y ayez accès. Si personne ne peut vous donner une adresse et un mot de passe pour y entrer, vous venez déjà de trouver quelque chose, et ce n'est pas un simple détail d'organisation.
De là découle la règle qui remplace tous les pourcentages du monde : si vous ne pouvez pas l'ouvrir sur votre propre téléphone et vous en servir, ce n'est pas fait, quoi qu'en dise le rapport. Cette règle a l'air brutale, elle est en réalité protectrice, parce qu'elle vous évite de payer pendant des mois un avancement dont personne ne peut administrer la preuve.
Le rythme sain, celui que nous tenons chez Linkysoft sur les développements sur mesure, se résume à une habitude : une démonstration de trente à quarante-cinq minutes chaque semaine, pendant laquelle c'est le client qui tient la souris. Pas une présentation commentée, pas des captures d'écran dans un document, pas une vidéo enregistrée où tout se passe bien. Vous cliquez, vous vous trompez, vous essayez ce qui n'était pas prévu au scénario, et en une demi-heure vous savez ce qui existe. Les projets de six mois menés sans cette séance hebdomadaire dérapent typiquement de 25 à 40 %, ce qui transforme six mois en sept mois et demi à huit mois et demi, alors qu'avec la démonstration et un registre écrit des changements nous voyons plutôt la dérive contenue sous 10 à 15 %.
Reste à s'entendre sur le mot terminé, qui est sans doute le mot le plus coûteux du secteur. Une fonctionnalité est terminée quand quatre cases sont cochées : elle est construite, elle est testée, vous l'avez vue et validée, et elle tourne sur le site de test. Quatre cases, pas une opinion. Un chantier sur mesure contient beaucoup plus que des écrans, et notre page consacrée au développement d'applications web détaille ce qu'un tel projet comprend réellement, ce qui aide à comprendre pourquoi une fonctionnalité peut sembler finie sans l'être.
Ce que contient un vrai point d'avancement, et ce qu'un point vague cache
Un compte rendu utile tient en trois parties et ne dépasse pas une page. D'abord ce qui est terminé depuis la dernière fois et que vous pouvez cliquer, avec le lien pour aller le vérifier vous-même. Ensuite ce qui est en cours en ce moment, avec une date de fin annoncée. Enfin ce qui est bloqué, accompagné du nom de la personne qui détient le déblocage, qu'il s'agisse d'un développeur, de votre comptable, de votre banque ou de vous. Tout ce qui n'entre pas dans ces trois cases relève du récit, pas du suivi.
Certains mots devraient déclencher chez vous une question supplémentaire, non parce qu'ils sont mensongers, mais parce qu'ils servent à amortir : presque, quasiment, on finalise, on peaufine, on attend deux ou trois choses, il y a des soucis d'intégration. Ajoutez-y toute phrase sans sujet ni objet clairs, du genre on avance bien sur la partie commandes. Votre relance est alors toujours la même, et elle reste aimable : très bien, sur quoi puis-je cliquer aujourd'hui, et que reste-t-il exactement à faire ?
Un mot sur les blocages, parce qu'ils sont mal vus à tort. Une équipe qui nomme ses blocages est une équipe qui sait où elle en est, ce qui est précisément la qualité que vous cherchez ; une équipe qui n'en a jamais est en général une équipe qui les cache, ou qui ne les voit pas encore, et les deux cas finissent de la même manière deux mois plus tard.
Si vous préférez copier des phrases toutes faites plutôt que d'expliquer un malaise, voici trois questions à envoyer telles quelles par courriel :
- Quelle est l'adresse du site de test, et quelles fonctionnalités puis-je y utiliser de bout en bout dès aujourd'hui ?
- Combien d'éléments de la liste initiale sont terminés selon notre définition en quatre points, et combien en reste-t-il ?
- Qu'est-ce qui est bloqué en ce moment, depuis quelle date, et qui doit agir pour le débloquer ?
Cinq vérifications à faire cette semaine, sans aucune compétence technique
Ces cinq contrôles demandent une heure au total, se mènent avec un téléphone et un carnet, et donnent une image plus fidèle que n'importe quel tableau de bord. Faites-les dans l'ordre, parce que chacun éclaire le suivant.
- Le test du clic, dix minutes. Ouvrez le site de test sur votre propre téléphone, pas sur l'ordinateur d'un développeur, et accomplissez une tâche complète du début à la fin comme le ferait un client : créer un compte, passer une commande, la retrouver le lendemain. Une tâche que l'on ne peut pas terminer n'est pas une tâche à moitié faite, c'est une tâche qui ne rapporte encore rien.
- Le test du registre des changements, quinze minutes. Demandez la liste écrite de toutes les demandes de modification formulées depuis le début, avec le nombre de jours que chacune a coûté. Si ce document n'existe pas, le planning ne peut pas être réel, puisque personne n'a jamais retranché le temps consommé par les ajouts.
- Le test du registre des anomalies, dix minutes. Demandez combien de problèmes sont ouverts aujourd'hui et combien l'étaient il y a un mois, puis comparez les deux nombres sans rien y ajouter. Le sens de la pente vous en apprendra plus que n'importe quel pourcentage d'avancement.
- Le test du périmètre face aux factures, vingt minutes. Posez la liste des fonctionnalités prévues au départ à côté du montant déjà dépensé, et comptez uniquement celles que vous pouvez cliquer, jamais celles qui sont en cours. Une fonctionnalité en cours vaut zéro tant qu'elle n'est pas utilisable, exactement comme une commande non livrée.
- Le test des deux personnes, cinq minutes. Demandez séparément à deux membres de l'équipe ce qui est prévu la semaine prochaine. Deux réponses différentes signifient que le plan vit dans la tête d'une seule personne, et un plan qui vit dans une seule tête disparaît le jour où cette personne tombe malade ou part en congé.
Aucune de ces vérifications n'est une accusation, et c'est important de le dire à l'équipe avant de commencer, parce que le ton conditionne la qualité des réponses. Une équipe solide y verra l'occasion de montrer son travail, tandis qu'une équipe en difficulté vous répondra par des délais. Si vous voulez comprendre en amont ce que recouvrent les tests dont on vous parlera pendant la réunion, notre blog y consacre d'autres articles.
L'arithmétique d'un planning, à la portée de tout le monde
Cessez de compter des pourcentages et commencez à compter des éléments, car un pourcentage est une opinion tandis qu'un élément terminé est un fait. La question à poser tient en une ligne : sur les quatre dernières semaines, combien de choses ont été réellement terminées et sont cliquables aujourd'hui ? Ce chiffre est la vitesse réelle de l'équipe, quoi que raconte le plan initial.
Prenons un exemple que vous pouvez refaire sur un coin de table. Votre projet comporte soixante éléments au total, vingt-cinq sont terminés et cliquables, et sur le dernier mois l'équipe en a bouclé trois par semaine. Il en reste donc trente-cinq, que l'on divise par trois, ce qui donne environ douze semaines, et non les six semaines inscrites au planning. Personne n'a triché : le plan a simplement été écrit avant que la vitesse réelle soit connue, et il n'a jamais été corrigé depuis.
Il faut ensuite corriger la capacité, parce que c'est là que se cache une bonne partie de l'optimisme. Une personne présentée comme travaillant à temps plein donne en pratique 25 à 30 heures utiles sur ses 40 heures, une fois retirés les réunions, les relectures, le support des projets précédents et le temps de reprendre le fil après chaque interruption. Un planning construit sur des semaines de 40 heures est donc optimiste de 25 % au mieux et de près de 40 % à l'autre bout de cette fourchette, avant même le premier incident.
Reste le piège des 90 %, celui qui coûte le plus de nuits blanches. Une fonctionnalité annoncée à 90 % demande en général encore 20 à 40 % de son estimation d'origine pour être vraiment close, car ce qui reste n'est pas le travail visible : c'est le raccordement au reste du système, les cas particuliers et les tests. Sur une fonctionnalité estimée à dix jours, 90 % veut donc dire deux à quatre jours restants, pas une demi-journée, et si vous avez huit fonctionnalités dans cet état, vous venez de retrouver un mois entier caché dans les arrondis.
Le travail que vous ne voyez pas, et pourquoi les écrans ne sont qu'un tiers du chantier
La plus grande source de malentendus tient à ceci : ce que vous voyez pendant une démonstration ne représente qu'un tiers environ du travail à fournir. Le reste existe bel et bien, il est seulement invisible. Il s'agit de décider qui a le droit de voir quoi, de brancher le système sur les services de paiement, de livraison ou de comptabilité, de faire passer les anciennes fiches clients et l'historique dans le nouvel outil sans en perdre une, de tester, de fermer les portes que la sécurité impose de fermer, de mettre en place des sauvegardes vérifiées, puis d'assurer la mise en ligne elle-même.
La conséquence pratique vaut la peine d'être retenue, car elle change la lecture d'un budget. Quand les maquettes sont validées et que les écrans sont beaux, à peu près un tiers du travail est derrière vous, ce qui veut dire qu'un projet ayant consommé la moitié de son budget à ce stade se porte plutôt bien, alors qu'un projet qui en a dépensé 80 % au même moment est déjà dans le mur, même si tout le monde sourit encore autour de la table.
La part de sécurité mérite une mention particulière, parce qu'elle ne se voit jamais dans une démonstration. Séparer les droits d'accès, protéger les données personnelles, résister aux tentatives d'intrusion automatiques et savoir restaurer une sauvegarde représente un travail réel que vous ne pourrez jamais cliquer, et c'est exactement pour cela qu'il est le premier à être sacrifié quand le calendrier se tend. Notre page sur la cybersécurité décrit ce que recouvre cette part du chantier, et il vaut mieux la comprendre avant la mise en ligne qu'après le premier incident.
Où les projets perdent réellement leurs semaines, et c'est rarement le code
Quand un projet dérape, le premier réflexe consiste à soupçonner les développeurs, et c'est presque toujours le mauvais endroit où regarder. Par ordre d'importance, les semaines perdues viennent des décisions qui attendent une réponse du client, du périmètre ajouté en cours de route sans replanification, des services extérieurs comme une passerelle de paiement, une banque ou un portail administratif, des tests systématiquement sous-estimés, et enfin de l'indisponibilité d'une personne clé, en congé, malade ou happée par un autre dossier.
Soyons directs sur votre propre part, car elle est plus lourde qu'on ne l'imagine. Un projet normal réclame 12 à 20 décisions de la part de l'acheteur : le mode de calcul d'une remise, le texte d'un courriel automatique, la personne qui valide un remboursement, le format d'une facture. La plupart de ces attentes ne coûtent rien, parce que l'équipe passe entre-temps à autre chose, et les seules qui pèsent sont les quelques décisions qui bloquent la suite du travail : il suffit de deux ou trois d'entre elles, immobilisées une semaine chacune, pour obtenir les deux semaines et demie du graphique ci-dessus, pendant que l'équipe de développement ne commet aucune faute. C'est une mauvaise nouvelle sur le moment et une excellente nouvelle sur le fond, puisque cette part du retard est celle que vous contrôlez entièrement.
Le périmètre mérite la même franchise. Un projet de quatre mois dont le contenu bouge de 15 à 30 % est un projet normal, souvent même un projet sain, parce que l'entreprise apprend en voyant l'outil prendre forme. Ce qui n'est pas sain, c'est d'accepter un changement sans noter par écrit combien de jours il coûte et de quelle date il décale la livraison, car c'est ainsi qu'un planning devient une fiction à laquelle plus personne ne croit sans oser le dire.
Le remède ne coûte rien : une liste écrite des décisions en attente, avec à côté de chacune un nom et une date, relue au début de la même réunion hebdomadaire que la démonstration. Trois minutes par semaine suffisent, et c'est le seul point de la réunion qui agisse directement sur la plus grosse part du retard, celle qui dépend de vous.
Les signaux qui veulent dire quelque chose, et le bruit qui n'en dit rien
Beaucoup de dirigeants s'inquiètent au mauvais endroit, ce qui use la confiance sans rien améliorer. Une date manquée sur une fonctionnalité isolée n'est pas un signal, c'est la vie normale d'un chantier. Un écran intermédiaire laid non plus, pas plus qu'une semaine de congé prise par un développeur ou qu'une page d'administration à l'allure rustique que personne en dehors de votre bureau ne verra jamais. Ces choses agacent, elles ne prédisent rien.
Les vrais signaux sont d'une autre nature, et ils sont peu nombreux : deux démonstrations consécutives sans rien de nouveau à cliquer, une liste de problèmes ouverts qui monte trois semaines de suite, une proposition soudaine de tout réécrire depuis le début, une définition du mot terminé qui se déplace discrètement d'une réunion à l'autre, et le silence, qui est de loin le plus fiable des cinq. Une équipe qui va bien parle ; une équipe qui va mal se fait rare, puis répond par des messages toujours plus longs et toujours moins précis.
Il existe une arithmétique très simple pour les anomalies, et elle vaut d'être retenue. Dans les six semaines qui précèdent une mise en ligne, un projet en bonne santé ferme plus de problèmes qu'il n'en ouvre, trois semaines de suite. Si la liste des problèmes ouverts monte trois semaines d'affilée, la date de lancement a déjà bougé, que quelqu'un l'ait dit à voix haute ou non, et il vaut mieux en tirer les conséquences tout de suite plutôt que de l'apprendre la veille. C'est aussi la période où les questions de sécurité remontent en surface, parce qu'elles ont souvent été repoussées quand le calendrier s'est tendu.
Lire l'argent dépensé en face du travail livré
La vérification budgétaire tient en une ligne et se fait en cinq minutes : comparez le pourcentage de l'argent dépensé au pourcentage des fonctionnalités que vous pouvez cliquer. Un budget consommé à 70 % en face de 40 % de fonctionnalités utilisables signifie que les 30 % de budget restants devront porter 60 % du travail, ce qu'ils ne feront pas. Ce n'est pas un pressentiment, c'est une division, et elle se pose sans connaître le métier.
Cette lecture devient beaucoup plus facile quand les jalons de paiement sont adossés à quelque chose que vous pouvez ouvrir et utiliser plutôt qu'à des mois de calendrier, parce qu'un jalon calendaire paie du temps alors qu'un jalon utilisable paie de l'avancement. Chez Linkysoft, nous découpons les chantiers de cette façon, et nos études de cas montrent comment un projet se répartit concrètement en étapes payées à la livraison de quelque chose de fonctionnel.
Dernier point, souvent oublié au moment de bâtir le budget : un logiciel ne s'arrête pas le jour de sa mise en ligne. Prévoyez chaque année 15 à 20 % du coût de construction pour l'hébergement, les mises à jour, les correctifs de sécurité et les petites évolutions que toute entreprise finit par demander. Un projet construit sans cette ligne budgétaire ne tombe pas en panne à une date précise, il se laisse simplement distancer, parce que les navigateurs et les téléphones évoluent et que plus personne n'applique les mises à jour nécessaires, et l'entreprise conclut alors à tort que le logiciel était mauvais, alors qu'il n'a simplement jamais été entretenu.
Vous découvrez que vous êtes en retard. Et maintenant ?
Il n'existe que quatre leviers, et tout le reste n'en est qu'une combinaison : réduire le périmètre, déplacer la date, ajouter de l'argent, ou arrêter. Nommer les quatre à voix haute rend la conversation étonnamment plus simple, parce que la discussion cesse de porter sur les responsabilités et se met à porter sur un choix.
Le levier de l'argent, sous sa forme la plus courante, consiste à ajouter des personnes, et c'est le plus lent de tous. Une équipe qui construisait passe deux à quatre semaines à expliquer au lieu de produire, si bien que le projet ralentit d'abord avant d'accélérer, et sur un projet qui doit livrer dans six semaines cette opération n'apporte rien.
La meilleure réponse est presque toujours la même : lancer une première version plus petite. Soixante pour cent du périmètre mis en ligne trois mois plus tôt commence à rapporter, recueille de vrais retours d'utilisateurs et finance souvent le reste, alors que les quarante pour cent gardés au chaud contiennent d'ordinaire une bonne part de ce que vous auriez de toute façon modifié après le lancement.
Quel que soit le levier choisi, la remise à plat s'écrit sur une page : nouvelle date, nouveau périmètre, ce qui a changé, pourquoi, et l'accord des deux parties par écrit. Une remise à plat non écrite n'est pas une décision, c'est un nouveau glissement silencieux, et vous vous retrouverez au même point deux mois plus tard avec deux mois supplémentaires dans le dos.
Si le levier retenu est l'arrêt, voici les chiffres qui évitent d'y voir un échec personnel. Reprendre un développement abandonné coûte en général 40 à 70 % du prix d'une construction neuve et exige trois à six semaines rien que pour comprendre ce qui existe déjà, avant la première ligne utile. Autrement dit, arrêter tôt un projet qui n'aurait pas dû commencer revient presque toujours moins cher que le pousser jusqu'à une mise en ligne dont personne ne voudra.
Quand la solution plus petite et moins chère est la réponse honnête
Faisons la comparaison à voix haute, puisque personne ne la fait spontanément. Un outil du commerce à 30 à 80 dollars par mois représente 360 à 960 dollars par an, face à un développement sur mesure qui démarre en général entre 8 000 et 25 000 dollars, auxquels s'ajoutent 15 à 20 % de cette somme chaque année. L'écart est tel que le sur mesure exige une vraie raison, et la préférence esthétique ou l'envie d'avoir quelque chose à soi n'en est pas une.
Trois raisons justifient réellement de construire. La première est un mode de fonctionnement qu'aucun produit du marché ne sait reproduire, parce qu'il constitue justement votre avantage. La deuxième est une obligation de conserver vos données chez vous, pour des motifs réglementaires ou contractuels. La troisième est une facturation par utilisateur qui, en grandissant, finit par dépasser le coût d'une construction : trente utilisateurs à 60 dollars par mois représentent 21 600 dollars par an, et le calcul se retourne alors tout seul.
Nous préférons le dire clairement : chez Linkysoft, il nous arrive de refuser un projet et d'orienter le client vers un outil existant, parce qu'un système qui n'aurait jamais dû être construit ne sera jamais dans les temps, quelle que soit la qualité de sa gestion. Un projet bien piloté vers un mauvais objectif reste un projet perdu, simplement mieux documenté.
Le rythme que vous pouvez instaurer dès lundi tient en trois habitudes : une démonstration cliquable chaque semaine, un recomptage des éléments restants chaque mois, et une fois par trimestre la question la plus saine de toutes, à savoir si cet outil rapporte toujours plus qu'il ne coûte. Ces trois habitudes valent mieux que n'importe quel logiciel de suivi, et elles ne coûtent qu'une heure par mois.
Si vous voulez un second avis sur votre chantier en cours, envoyez-nous vos trois chiffres, le nombre d'éléments prévus, le nombre d'éléments cliquables et le pourcentage de budget consommé, et nous vous dirons franchement ce que nous en pensons depuis la page contact, y compris quand la réponse consiste à ne rien construire du tout. Pour un besoin plus modeste, un site vitrine ou une boutique bien faite suffisent souvent, et notre conception et développement web couvre ce terrain-là ; si c'est la question du budget qui vous préoccupe avant tout, commencez par la comparaison ci-dessus avant de demander le moindre devis.
