Avant de créer ta propre plateforme interne, fais le calcul

« On va juste la développer nous-mêmes », dit-on généralement avec assurance et une estimation approximative des effectifs nécessaires. Six mois plus tard, l’équipe qui était censée y consacrer deux sprints en est encore à la maintenir un an après, et la plateforme qui devait faire gagner du temps aux développeurs est devenue l’une des choses qui leur en prend.

Développer en interne n’est pas forcément une mauvaise décision. Parfois, c’est la bonne. Ce qui manque le plus souvent, c’est le chiffre que les équipes oublient de prendre en compte avant de se décider, celui qui n’apparaît qu’une fois la décision déjà prise.

L’estimation de développement n’inclut presque jamais la maintenance

Point clé : la mise en place initiale ne représente qu’une infime partie du coût total. La facture qui ne cesse d’arriver est celle que personne n’avait prévue dans le budget.

Une proposition de développement chiffrera généralement le travail nécessaire à la mise en place de la plateforme : provisionnement, configuration CI/CD, modèles d’environnement, contrôles d’accès. Ce qu’elle chiffrera rarement, c’est ce qui se passe après le lancement. Quelqu’un doit appliquer un correctif lorsqu’une dépendance fait l’objet d’un avis de sécurité. Quelqu’un doit l’étendre quand le processus d’une nouvelle équipe ne correspond pas à la conception initiale. Quelqu’un doit être suffisamment calé pour le déboguer à 23 h quand ça plante.

Cette personne est généralement un ingénieur senior, et les heures qu’il passe à faire tourner la plateforme interne sont des heures qu’il ne consacre pas au produit que l’entreprise vend réellement. Le nombre de sprints indiqué dans la proposition initiale n’a jamais été le chiffre qui comptait. Ce qui compte, c’est le nombre d’heures d’ingénieur senior par mois que cela nécessite indéfiniment, et ce que ces heures pourraient produire d’autre à la place.

Le coût d’achat est visible. Le coût de développement est juste plus difficile à percevoir

Point clé : les deux options coûtent de l’argent. L’une apparaît sous forme de ligne budgétaire que quelqu’un doit approuver. L’autre se répartit entre les personnes, le temps et les opportunités, ce qui explique justement pourquoi on la sous-estime si facilement.

L’envie de développer soi-même vient souvent d’une préoccupation légitime : la tarification d’un fournisseur, basée sur les ressources, est une ligne budgétaire que quelqu’un doit approuver, tandis que le temps passé par les ingénieurs en interne semble « gratuit » puisqu’il est déjà inclus dans la masse salariale. Ce temps « gratuit » est pourtant déjà payé, sous forme de salaire, et chaque heure passée à entretenir les outils de la plateforme interne est une heure qui n’est pas consacrée à ce qui a justifié l’embauche de cet ingénieur au départ.

Acheter, c’est échanger un coût variable et caché contre un coût fixe et visible. Ce compromis vaut le coup dès lors que le travail sur la plateforme en lui-même n’apporte pas de valeur ajoutée à l’entreprise, et pour la plupart des entreprises, la mise en place et la standardisation des environnements n’en apportent tout simplement pas.

L’option hybride que la plupart des équipes négligent

Point clé : « développer » et « acheter » ne sont pas les deux seules options possibles. Acheter la base standardisée et ne développer que la fine couche véritablement spécifique à ton activité s’avère souvent plus judicieux que de miser tout sur l’un ou l’autre extrême.

Le débat « développer ou acheter » présente ça comme un choix binaire, mais la plupart des modèles de déploiement regroupent deux types de travail très différents : l’infrastructure de base dont toute entreprise a besoin (provisionnement, cohérence des environnements, contrôle d’accès, retour en arrière) et les quelques éléments qui sont vraiment spécifiques à la façon dont cette entreprise en particulier déploie ses logiciels. L’infrastructure de base vaut rarement la peine d’être développée. La partie spécifique, en revanche, le vaut parfois.

Une approche hybride consiste à acheter la base standardisée auprès d’un fournisseur et à réserver le temps d’ingénierie de l’équipe à la couche supérieure qui différencie réellement l’entreprise : une porte de déploiement personnalisée liée à un processus de conformité propriétaire, par exemple, ou un outil interne qui s’intègre à un processus qu’aucun fournisseur n’a de raison de prendre en charge. C’est un développement bien plus restreint qu’une plateforme interne complète, et ça s’accompagne de coûts de maintenance bien moindres.

La vraie question, c’est de savoir quelles parties de ce que tu prévois de développer sont réellement propres à ton entreprise, et lesquelles correspondent aux mêmes problèmes de provisionnement et de cohérence que toutes les autres équipes d’ingénierie ont déjà résolus – pas de savoir s’il faut développer ou acheter de manière abstraite.

Les chiffres à prendre en compte avant de te décider

Point clé : trois chiffres transforment le débat « développer ou acheter » en un simple calcul.

Avant de t’engager dans une direction ou l’autre, ça vaut le coup de mettre des chiffres concrets sur trois questions :

1. Que coûterait réellement le développement, y compris la deuxième année ?
   Pas seulement l’estimation initiale du sprint, mais une allocation réaliste pour la maintenance continue : correctifs, mises à jour, intégration des nouveaux membres de l’équipe à un système sur mesure, et gestion des cas particuliers qui apparaissent une fois que de vraies équipes commencent à l’utiliser.
2. À quoi ce temps d’ingénierie pourrait-il servir à la place ?
   Si ces mêmes ingénieurs seniors consacraient ce temps à la feuille de route du produit, quelle en serait la valeur, que ce soit en termes d’impact sur le chiffre d’affaires ou en termes d’économie réalisée en n’embauchant pas une personne supplémentaire pour s’en charger ?
3. Combien coûte réellement une solution « suffisamment bonne » ? Pas seulement le prix affiché, mais en le comparant au coût de maintenance évoqué dans la première question, sur le même horizon temporel. Un projet qui semble moins cher sur un trimestre s’avère souvent plus coûteux sur deux ans.

Pour te faire une idée des chiffres, prenons un exemple illustratif, pas une référence vérifiée : trois ingénieurs seniors, chacun consacrant un cinquième de son temps à la maintenance de la solution, un ratio réaliste pour une plateforme de taille moyenne. Avec un coût total d’environ 180 000 $ par an et par ingénieur, ce cinquième de leur temps représente environ 108 000 $ par an, chaque année, sans compter ce que ces ingénieurs n’ont pas pu développer à la place.

Si on compare ça au prix fixé par un fournisseur en fonction des ressources pour une base standardisée équivalente, le résultat est souvent très différent de l’estimation initiale sur un sprint unique qui avait permis de faire valider le projet au départ.

Fais le calcul pour de vrai, avec tes propres chiffres, en parallèle des deux autres questions, et le débat a tendance à se régler tout seul. Ça ne relève plus d’une question de principe, ça devient un simple tableur.

Quelle que soit la direction que prennent les chiffres – développement, achat ou solution hybride –, la base standardisée sous-jacente reste la même : des environnements provisionnés de manière cohérente, généralement la partie du modèle de livraison qui vaut le plus la peine d’être achetée plutôt que développée, que ce soit sur Upsun ou ailleurs.

À lire aussi : 7 points faibles de ton modèle de déploiement à corriger avant ton prochain audit ou ta prochaine panne

Tu veux avoir une vision claire de ce que coûterait réellement à ton équipe la construction de ta propre plateforme, en fonction de ta configuration ? Réserve un bilan de standardisation de plateforme.

Foire aux questions (FAQ)

Est-ce qu’il est parfois judicieux de développer une plateforme en interne plutôt que de l’acheter ?
Oui, lorsque le travail sur la plateforme lui-même apporte une réelle valeur ajoutée à l’entreprise, ou lorsque les exigences sont suffisamment atypiques pour qu’aucune solution fournisseur ne convienne sans personnalisation importante. Pour la plupart des processus standard de mise à disposition et de livraison d’environnements, il n’y a pas de valeur ajoutée, c’est pourquoi le coût de maintenance est rarement rentabilisé.

Quel est le coût le plus souvent sous-estimé dans une décision de développement ?
La maintenance continue. La plupart des estimations de développement tiennent compte du calendrier initial du projet, mais pas des heures d’ingénierie récurrentes nécessaires pour maintenir la plateforme à jour, l’étendre et l’adapter aux besoins évolutifs de l’équipe.

Comment comparer équitablement le coût d’un développement à celui d’un achat ?
Compare-les sur la même période, généralement deux à trois ans, et inclue le coût en temps d’ingénierie nécessaire à la maintenance d’un développement, pas seulement le coût initial du projet. Le prix d’un fournisseur est visible d’emblée ; le coût réel d’un développement ne se révèle qu’au fil du temps.

Que doit faire une équipe avant de se décider ?
Comparer l’estimation de développement à des chiffres concrets, en incluant la maintenance des deuxième et troisième années, puis comparer ce total au coût d’achat sur la même période. La comparaison permet généralement de trancher d’elle-même.