Est-ce pertinent de changer de prestataire pour vos développements ?

Vous avez un prestataire, un logiciel qui tourne mais vous n’êtes pas pleinement satisfait du résultat. Les livraisons prennent du retard, une correction en casse une autre, la facture grimpe sans que le logiciel avance, et vous avez l’impression de ne pas parler la même langue. La question qui vient ensuite est toujours la même : est-ce lui ou est-ce moi ?

Cet article ne vous dira pas directement de changer car la question mérite une vraie réflexion. Nous allons détailler une à une, les quatre problématiques récurrentes que vous pouvez vivre dans cette relation. Pour chacune : ce qui se passe d’habitude derrière, en quoi vous y contribuez peut-être sans le savoir, et un moyen simple de le vérifier.

Nous terminerons sur une partie qui nous semble souvent sous-estimée : ce que votre prestataire fait peut-être sans que vous le voyiez, et une conclusion sur les deux issues possibles, parce qu’il y en a bien deux.

Nous espérons que ces quelques conseils vous permettront de sauver les relations qui le méritent et de vous sortir des autres.

1. Les délais : “je ne sais jamais où on en est”

Ce qui se passe derrière les délais

Un délai qui glisse une fois est un accident. Un délai qui glisse à chaque fois, sans explication, dit quelque chose du pilotage. Trois causes reviennent :

• L’estimation a été faite sans cadrage. On a chiffré une idée, pas un besoin décrit. Le travail réel se découvre en cours de route, et la date annoncée n’avait aucune chance.
• La capacité n’est pas là. Une personne partagée entre dix clients avance sur celui qui crie le plus fort. Votre projet attend son tour, et personne ne vous le dit.
• Le suivi n’existe pas. Le prestataire lui-même ne sait pas où en est votre projet. Il découvre le retard en même temps que vous.

Sur ce dernier point, le minimum n’est pas compliqué : un outil de gestion de projet, dans lequel chaque demande est découpée en tickets clairs, chacun avec sa liste d’actions à suivre. Ce n’est pas un luxe de grande équipe, c’est ce qui permet de répondre à “où en est-on ?” sans reconstituer la semaine de mémoire. Chez SmartBooster, quand un client nous pose la question, nous partageons le tableau en visio : la réponse est limpide, ticket par ticket, et elle est la même pour lui que pour nous.

Votre part dans les délais, peut-être

Le facteur qui pèse le plus sur un délai est rarement technique : c’est la disponibilité côté client. Une validation qui attend une semaine, trois personnes dans la boucle qui ne sont pas d’accord entre elles, une demande ajoutée en cours de route sans que personne n’ait redit la date. En pratique, sur les projets que nous menons, ce sont plus souvent les clients qui demandent de ralentir que l’inverse.

Un test simple sur les délais

Demandez à votre prestataire la liste de ce qui est en attente de vous, avec les dates. S’il peut vous la donner dans l’heure, il pilote : le retard a une cause, elle est peut-être chez vous, et vous pouvez agir. S’il ne peut pas dire ce qui bloque ni depuis quand, le problème est chez lui, et aucune bonne volonté de votre part ne le résoudra.

2. La qualité : “dès qu’on corrige, autre chose casse”

Ce qui se passe derrière la qualité

Une régression isolée arrive à tout le monde. La répétition, elle, décrit un dispositif. Quand chaque livraison casse quelque chose qui marchait, c’est presque toujours qu’il manque une des trois briques qui l’empêchent :

• des tests automatisés qui rejouent ce qui marchait avant, à chaque modification ;
• un environnement de recette distinct de la production, où vous voyez la livraison avant vos utilisateurs ;
• un ticket qui dit ce qui devait être vérifié, écrit avant de développer.

Sans ces trois briques, le développeur corrige à l’aveugle, et la régression n’est pas une faute : c’est une conséquence.

Il y a une quatrième cause, plus discrète, et elle se cache derrière une promesse rassurante : la structure assez grande pour vous garantir qu’il y aura toujours quelqu’un de disponible. C’est vrai, et c’est là que ça se joue. En pratique, plusieurs personnes se relaient sur votre projet, chacune redécouvre le code en arrivant, aucune ne reste assez longtemps pour s’intéresser à votre métier ni pour connaître les cas qui comptent chez vous. Ce que la première a compris, la troisième l’ignore, et c’est sur cet oubli que la régression arrive.

Votre part dans la qualité, peut-être

La recette est souvent le maillon que le client sacrifie. “Mettez en production, on verra” fait gagner deux jours et coûte une semaine. Une demande de modification passée en urgence par téléphone, sans ticket, ne sera testée par personne. Et un prestataire à qui l’on a refusé trois fois le budget de maintenance technique parce que “ça ne se voit pas” finit par ne plus le proposer.

Un test simple sur la qualité

Demandez comment une livraison est validée avant d’arriver chez vous. Vous n’avez pas besoin de comprendre la réponse technique, seulement de savoir si les trois briques existent : un environnement de recette, des tests qui tournent automatiquement, un ticket qui décrit l’attendu. Si aucune des trois n’existe, les régressions sont structurelles et le resteront. Si elles existent et que ça casse quand même, regardez qui a validé la dernière livraison, et en combien de temps.

3. Le coût : “chaque évolution coûte plus cher que la précédente”

Ce qui se passe derrière le coût

Il y a une raison légitime à ce que le coût monte : la dette technique. Un logiciel dont on n’a jamais mis à jour le socle, jamais nettoyé le code, jamais écrit les tests, devient plus lent à modifier chaque année. Le prestataire qui vous facture plus cher pour la même chose ne vous vole pas forcément : il compte dans sa mission le rattrapage des années de maintenance différée.

Il y a aussi des raisons moins légitimes : une facturation au temps sans périmètre écrit, des devis que vous ne pouvez pas rapprocher de ce qui a été livré. Ou le simple fait que rien n’est expliqué.

Votre part dans le coût, peut-être

Trois habitudes font grimper une facture sans que le prestataire y soit pour grand-chose :

• Formuler la demande en solution plutôt qu’en besoin. “Ajoutez un bouton ici” au lieu de “je dois savoir quand une commande est en retard”. La première se code, la seconde se réfléchit, et c’est souvent moins cher.
• Les micro-demandes au fil de l’eau. Dix demandes d’une heure coûtent plus que deux demandes d’une journée, parce que chacune a son coût de mise en route, de test et de livraison.
• Le refus de la maintenance préventive. Pendant des années, “on ne touche pas à ce qui marche”. Puis la montée de version obligatoire arrive, et tout est facturé d’un coup.
• Préciser la demande au moment des tests, comme s’il s’agissait d’un bug. “Ce n’est pas ce que je voulais” arrive à la recette, alors que le point aurait dû être fixé à la conception. Cela revient parfois à redévelopper des parties entières, et cela devient ingérable quand les retours arrivent un à un, chacun attendant la correction du précédent avant d’être formulé.

C’est pour cette dernière raison que nous cadrons, dès la conception, un jeu de données réaliste : vos vrais clients, vos vrais cas limites, vos vrais montants. Il sécurise le cadrage, parce qu’on découvre les questions sur des exemples concrets plutôt que sur un écran livré, et il positionne les retours de recette pour ce qu’ils sont : des améliorations, pas des bugs.

Un test simple sur le coût

Pour la dernière évolution facturée, demandez la part qui correspond à la fonctionnalité, et la part qui correspond à la remise en état préalable. Un prestataire qui sait distinguer les deux vous dira ce que la dette vous coûte et comment la réduire. Celui qui ne sait pas ne pilote pas ses coûts non plus, et vous ne saurez jamais ce que vous achetez. Nous avons écrit ailleurs un plan d’action pour réduire la dette technique qui donne la démarche.

4. L’incompréhension : “ils codent ce que je dis, pas ce dont j’ai besoin”

Ce qui se passe derrière l’incompréhension

Deux symptômes, une même cause. Le premier : la fonctionnalité livrée correspond à la demande, mot pour mot, et ne sert à rien. Le second : un choix technique qu’on ne vous explique jamais, “c’est comme ça”. Dans les deux cas, le prestataire n’a pas pris le temps de comprendre votre métier. Ou bien il l’a compris et ne sait pas le dire dans vos mots. Il n’y a pas eu de cadrage, et il n’y a plus de point régulier où l’on parle d’autre chose que de la prochaine livraison.

Votre part dans l’incompréhension, peut-être

Une demande transmise sans contexte, sans le pourquoi, sera codée telle quelle. Un seul interlocuteur chez vous qui traduit les besoins de dix personnes finit par transmettre des solutions, pas des problèmes. Et le point projet mensuel qu’on annule parce qu‘“il n’y a rien de nouveau” est exactement celui où l’incompréhension se serait vue.

Un test simple sur l’incompréhension

Deux questions, une par symptôme. Sur une fonctionnalité que vous venez de commander : “reformulez-moi, avec vos mots, à quoi elle sert et qui l’utilisera.” Sur un choix technique : “quelle était l’alternative, et pourquoi pas celle-là ?” Une réponse en une phrase que vous comprenez, et le prestataire sait ce qu’il fait. Pas de réponse, et le choix n’a pas été fait : il a été subi, par lui comme par vous.

De notre côté, nous avons travaillé cette question dans les deux sens. Pour que vos demandes arrivent avec leur contexte, nous avons écrit des modèles de documents, l’expression de besoin en premier, chacun accompagné d’un guide d’utilisation : un modèle sans explication ne sert à rien, il produit des cases remplies sans le pourquoi. Et pour que nos choix techniques ne soient pas des “c’est comme ça”, nous avons investi dans des articles pédagogiques sur ce site, pour que celui qui veut comprendre un sujet puisse le faire à son rythme, avant ou après le point projet : l’OWASP Top 10 ou la gestion des vulnérabilités CVE, par exemple.

Ce qui est peut-être en place, et que vous ne voyez pas

Une part du travail d’un bon prestataire est invisible par construction. Vous ne voyez rien dans votre logiciel, seulement des lignes en plus sur la facture. C’est le piège de la comparaison : celui qui fait ce travail sans le dire paraît cher et lent, celui qui ne le fait pas paraît rapide et bon marché, jusqu’au jour où ça compte. Et il y a une explication simple et fréquente, au silence du premier : il fait ces actions sans vous les rapporter parce qu’il ne pense pas que cela vous intéresse. Avant de juger, regardez ce que ce travail contient réellement.

L’entretien que personne ne voit

Les dépendances mises à jour, les correctifs de sécurité appliqués, le monitoring qui l’a réveillé à trois heures du matin, la sauvegarde dont il a testé la restauration, les tests écrits, la documentation tenue. C’est la partie la plus connue du travail invisible, et la plus facile à vérifier car elle laisse des traces.

La montée en compétence, dans un domaine qui accélère

Les heures passées à comprendre une nouvelle version, un nouvel outil, une nouvelle menace, pour que votre logiciel en profite sans que vous ayez à le demander. Le rythme s’est accéléré : les cycles de version se sont raccourcis, les alertes de sécurité se sont multipliées, l’outillage change chaque année. Un prestataire qui ne consacre pas de temps à ça finit par appliquer à votre logiciel ce qu’il savait il y a cinq ans. Et c’est loin d’être suffisant !

La recherche et la construction de nouveaux outils

C’est la partie que nous voulons rendre visible, parce que c’est celle qui nous coûte le plus cher et qui se voit le moins. Avant d’adopter un outil, il faut le comparer à ses alternatives, le tester sur de vrais projets, et décider. Nous publions ces analyses : ZAP et Nuclei pour les scans de sécurité, OSV-Scanner et l’audit des images Docker pour les dépendances, PHPStan face à Psalm pour l’analyse statique. L’effort d’analyse derrière chacun est important, et nous espérons que le détail des articles vous permet de l’apprécier, même sans en lire le code.

Cet effort produit ensuite des outils qui servent tous nos projets. Notre environnement de développement Symfony sous Docker est public sur GitHub : chaque projet démarre sur la même base, à jour, sans rejouer la configuration. Notre standard-bundle regroupe nos règles de validation de code et nos standards de développement, pour améliorer la qualité de nos projets Symfony de manière industrialisée plutôt que projet par projet. Et nos processus de montée de version sont écrits, comme le passage de Symfony 6 à 7 ou de PHP 7 à 8 : quand nous les appliquons chez vous, le chemin est déjà tracé. C’est ce qui nous fait gagner du temps par rapport à un prestataire qui vous facture tout son temps de découverte, et c’est ce que vous payez sans le voir.

Quatre questions dont la réponse ne se discute pas

• Sur quelle version de PHP et du framework tourne mon logiciel, et jusqu’à quand est-elle supportée ? Notre analyse de montée de version vous donne la réponse en ligne, et notre page sur la fin de support explique ce que la date veut dire.
• À quand remonte le dernier test de restauration d’une sauvegarde ? Pas la dernière sauvegarde : la dernière fois où quelqu’un a vérifié qu’elle se restaurait.
• Quand a eu lieu le dernier scan de sécurité, et qu’a-t-il trouvé ?
• Mon prestataire assure-t-il une veille, et m’a-t-il proposé une nouvelle solution cette année ? Une façon de faire plus simple, un outil qui a changé la donne, une pratique qu’il a adoptée : s’il ne propose jamais rien, soit il ne veille pas, soit il garde ce qu’il apprend pour lui.

Si les réponses arrivent, avec des dates, une part de ce que vous payez est justifiée, même si personne ne vous l’avait dit. Si elles n’arrivent pas, vous savez ce qui n’est pas fait.

Comment nous en rendons compte

Chez SmartBooster, nous ne produisons pas de reporting technique automatique : la liste des dépendances mises à jour cette semaine n’est pertinente pour presque aucun client, et un rapport que personne ne lit ne rend compte de rien. Nous préférons un point dédié, où nous prenons le temps de vous expliquer et de vous montrer ce que nous avons fait, en toute transparence, puis nous adaptons le reporting à ce qui vous est réellement utile.

Conclusion : deux issues possibles, laquelle sera la vôtre ?

Le plus souvent, c’est un cadre qui manque

Une mauvaise relation repose souvent sur des incompréhensions qui datent du premier jour. Personne n’a pris le temps de poser un cadre de travail partagé : qui décide chez vous, comment une demande s’écrit, comment une livraison se valide, à quel rythme on se parle, ce que “livré” veut dire, ce que la maintenance couvre et ne couvre pas. Chacun a travaillé avec ses propres règles, et chacun reproche à l’autre de ne pas les suivre.

Si les tests ci-dessus ont donné des réponses, même imparfaites, la relation vaut probablement d’être cadrée avant d’être rompue. Proposez à votre prestataire de poser ce cadre par écrit, en une réunion. S’il accepte, vous venez de vous épargner six mois de transition. Un référentiel commun défini tard vaut mieux que pas de référentiel du tout.

Si vous avez besoin d’aide dans la démarche ou le diagnostic de la situation, nous pouvons vous proposer un audit de votre projet adapté à votre situation : état du code, outils de développement, conception, gestion de projet, hébergement, sécurisation. Il met en avant ce qui fonctionne bien des deux côtés, chez vous comme chez votre prestataire, et propose des axes d’amélioration concrets pour remettre l’organisation sur une bonne base, sans forcément reprendre votre projet.

Parfois, il faut simplement l’admettre

Et parfois la relation n’est pas productive, et elle ne le deviendra pas. Les tests restent sans réponse, chaque échange est une négociation, et vous passez plus de temps à argumenter qu’à faire avancer votre logiciel. Le temps passé à convaincre un prestataire de travailler autrement est du temps que votre entreprise ne récupérera pas.

Dans ce cas, admettez-le, sans en faire une faute, ni la vôtre ni la sienne, et cherchez un partenaire plus adapté. Un projet peut changer de mains sans être refait : c’est la reprise, et c’est un métier.

Ce que nous faisons pour que la question ne se pose pas

Nous avons écrit cet article parce que nous voulons être jugés sur ces critères. Voici ce que SmartBooster met en place, dès le premier jour, pour que la relation ne dérive pas. Ce ne sont pas des promesses, ce sont des pages que vous pouvez lire avant de nous appeler.

• Notre méthode est publique. Le playbook SmartBooster décrit comment nous travaillons : comment un ticket se rédige, comment les cas de test se préparent avant de développer, comment une livraison se valide, et le point projet où l’on parle d’autre chose que de la prochaine livraison. Ce cadre de travail partagé, celui qui manque dans la première issue, vous l’avez avant de signer.
• Nos services sont décrits en détail, ce qu’ils couvrent et ce qu’ils ne couvrent pas : le développement sur mesure, la maintenance évolutive et le prototype. Vous savez ce que vous achetez, et vous pouvez nous le rappeler.
• Le contrat de maintenance se dimensionne. Fréquence des mises à jour de sécurité, périodicité du scan, niveau de suivi du monitoring, rythme des mises à jour du socle : la grille du contrat vous laisse choisir, poste par poste, ce qui convient à votre exposition et à votre budget. Le travail invisible cesse de l’être : il est écrit, et vous l’avez choisi.
• Les montées de version se voient venir. L’analyse de montée de version est en ligne, gratuite, et dit pour votre logiciel ce qui arrive en fin de support et quand. Vous n’avez pas à nous croire sur parole : l’outil dit la même chose à tout le monde.
• Nos pratiques s’appuient sur des standards reconnus, pas sur notre seul avis : OWASP pour la sécurité, le versionnement sémantique pour les mises à jour, les bases CVE pour les vulnérabilités. La page normes et standards dit lesquels, et ce que nous en faisons.

Si vous êtes dans la seconde issue, l’audit de code est le premier pas : un rapport que vous pouvez lire, en quelques jours, qui dit ce qui est récupérable en l’état. Y compris quand la conclusion est que votre prestataire actuel fait correctement son travail. Nous l’écrirons aussi.