Deux façons d'acheter du développement
Le projet au forfait est un achat de livrable. Vous décrivez ce que vous voulez, le prestataire s'engage sur un prix et une date, et la relation se termine à la recette. C'est le format naturel pour construire quelque chose qui n'existe pas encore.
L'équipe dédiée, souvent appelée squad, est un achat de capacité. Vous réservez pour plusieurs mois des profils identifiés, qui travaillent uniquement pour vous et qui restent d'un sprint à l'autre. Vous n'achetez pas un périmètre, vous achetez la faculté d'en traiter un nouveau tous les quinze jours.
Confondre les deux produit les deux erreurs les plus fréquentes : payer une équipe permanente pour un besoin qui s'arrête dans trois mois, ou enchaîner des forfaits successifs sur un produit qui aurait justifié une équipe stable.
Ce que l'équipe dédiée apporte et que le forfait ne peut pas fournir
La connaissance qui reste
Sur un projet au forfait, une équipe apprend votre métier pendant le cadrage et les premiers sprints. Cette connaissance atteint son maximum au moment de la recette, c'est-à-dire précisément quand la relation s'arrête. Au projet suivant, une partie est à reconstituer.
Une équipe dédiée capitalise. Au bout de six mois, elle sait pourquoi telle règle de facturation existe et quelles conséquences aura un changement de modèle de données. Cette connaissance ne se facture pas, mais c'est elle qui fait qu'un chiffrage passe de dix jours à trois.
L'absorption de l'imprévu
Un bug bloquant en production ne se planifie pas. Avec une équipe dédiée, il entre dans le sprint en cours au prix d'un arbitrage de priorité. Avec un forfait, il tombe hors périmètre : il faut le qualifier, le chiffrer, le faire valider, et pendant ce temps il est toujours en production.
Le rythme
Un produit vivant a besoin d'un flux régulier, pas de gros jalons espacés. Livrer toutes les deux semaines change la façon dont les utilisateurs remontent leurs besoins : ils savent que la remontée servira. C'est un effet organisationnel, et il est net.
Ce que le forfait apporte et que l'équipe dédiée ne garantit pas
Un engagement de résultat. C'est la différence essentielle, et elle est structurelle : une équipe dédiée s'engage sur une disponibilité, pas sur le contenu d'une livraison à six mois. Si votre banque, votre régulateur ou votre plus gros client attend une fonctionnalité à une date, cet engagement doit exister quelque part, et seul le forfait le porte.
Le forfait apporte aussi une discipline de périmètre. Comme tout ajout se voit, personne ne construit par inadvertance des fonctionnalités que personne n'utilisera. Une équipe dédiée mal pilotée produit exactement ce travers : elle est occupée, donc elle produit, mais la valeur de ce qu'elle produit n'est jamais interrogée.
Enfin, il correspond à la réalité budgétaire de beaucoup d'organisations : un investissement voté une fois, sur un objet identifié, est souvent plus facile à faire passer qu'une charge mensuelle permanente.
Le seuil à partir duquel l'équipe dédiée devient rentable
La bascule n'est pas une question de taille d'entreprise, c'est une question de flux. Le signal le plus fiable est celui-ci : vous avez lancé trois projets au forfait en dix-huit mois auprès du même prestataire, sur le même logiciel.
À ce stade, vous payez trois fois une phase de cadrage, trois fois une montée en contexte, et vous subissez trois fois le délai administratif entre le besoin et le démarrage. Une équipe dédiée supprime ces trois coûts d'un coup.
Le signal inverse existe aussi : si l'équipe passe une partie de ses sprints à chercher quoi faire, votre besoin ne justifie pas encore une capacité permanente. Revenez au forfait, sans regret. Une squad sous-alimentée coûte cher et démobilise.
Le passage de l'un à l'autre
La séquence la plus solide commence par un forfait et se poursuit en équipe dédiée. La première version se construit avec un engagement de périmètre, de délai et de budget, ce qui est le moment où le risque est maximal. Une fois le logiciel en production et adopté, la même équipe bascule en capacité dédiée pour le faire vivre.
L'intérêt est que la connaissance acquise pendant la construction n'est pas perdue : ce sont les personnes qui ont écrit le code qui le font évoluer. C'est le montage que nous mettons en place le plus souvent, et c'est aussi le plus lisible budgétairement, puisque l'investissement initial et le coût de fonctionnement restent deux lignes distinctes.
