En devenant client chez nous, vous achetez du code. A la fin du projet, nous vous remettrons un dossier contenant des centaines de fichiers de code source. Ce dossier, vaut probablement une somme à 6 chiffres.
Qu’un simple dossier puisse coûter autant, je trouve cela fou. Pas vous ?
Et pourtant il les vaut !
Une autre question : Avez-vous seulement acheté du code ?
Aujourd’hui, je vous propose de comprendre les enjeux autour d’un développement afin que vous puissiez anticiper et maitriser votre investissement, chez nous comme chez un concurrent.
Bonne lecture !
En investissant dans le développement d’une application, d’un logiciel, d’une IA, vous allez nécessairement devoir anticiper 4 grandes sources de coûts. Nous détaillerons ici uniquement les coûts relatifs à la création et à l’exploitation de la solution.
Pensez à anticiper les coûts d’adoption qui seront, même avec le meilleur produit au monde, très importants. Pour de l’interne, nous parlons de coûts de communication et de formation. Pour de l’externe, de coûts marketing et commerciaux. Dans les 2 cas, ces coûts (en temps et en argent) ne doivent pas être négligés.
Le coût principal de votre investissement est le coût humain associé à la création du code source. Généralement, il s’agit d’un multiple entre le Taux Journalier d’un expert technique et le temps passé.
Les compétences autour du développement coûtent cher, pour plusieurs raisons :
Ainsi prévoyez à minima :
D’ailleurs, la plupart des produits digitaux que vous utilisez sont à minima des V5 et plus. Elles ont nécessité des années de travail par des équipes, voir des bataillons, d’ingénieurs.
Les coûts de développement englobent de nombreux travaux, une section leur est dédiée plus bas. Retenez simplement que les coûts de développement sont les coûts principaux relatifs à la création et à l’exploitation d’une solution digitale, au début mais aussi tout au long de la vie du produit. La raison sera détaillée dans la dernière section de cet article.
Eh oui, malheureusement une solution digitale nécessite de la maintenance et du support dès sa sortie d’usine et pour le restant de ses jours. Plus ou moins en fonction des projets et de la qualité des développements, mais il y en aura toujours.
Pourquoi ?
Plus vous aurez des utilisateurs, plus la masse testera tout, son contraire et le contraire de son contraire. Même des cas absurdes, grotesques, inimaginables. Et un bug surviendra. Puis un autre, puis autre.
Une bonne équipe de développement en anticipera infiniment plus qu’une mauvaise, mais à la fin, des bugs apparaitront. Nécessairement.
Vous aurez donc besoin d’un support pour recueillir les témoignages, les comprendre et les traiter.
A cela s’ajoutent les mises à jours. Votre solution reposera sur un tas de technologies développées par des tiers : OS, librairies, frameworks, API. Chaque mise à jour ou correctif de sécurité d’un composant peut avoir un impact sur votre solution.
2 options s’offrent à vous :
C’est pourquoi nous fournissons à nos clients une offre de “Maintenance et Support” dont le prix s’élève à 1.25% par mois des coûts de développement. C’est un standard dans notre milieu. Ainsi, si votre solution a couté 100k€ à développer, vous devez prévoir 1250€ / mois en maintenance et support technique.
Il s’agit du coût d’exploitation le plus cher en général, mais vous avez 2 autres coûts à anticiper.
Si votre solution est accessible via le web (très probable en 2024), vous aurez des coûts d’hébergement. Vous paierez 2 types d’hébergement :
En moyenne, nos clients paient environ 50€ / mois pour un staging et 200€ / mois pour une production. Cela varie du tout au tout en fonction du nombre d’utilisateurs et de la puissance de calcul nécessaire. De plus, si vous hébergez des données de santé, il vous faudra souscrire à un “Hébergement De Santé” (HDS). Le budget mensuel s’en verra à minima doublé…
Attention aux hébergements proposés par les GAFAM. En plus d’être en conflit avec le RGPD, leur système tarifaire est opaque. Les premiers mois, ils proposent souvent des crédits gratuits. Une fois la migration d’hébergements devenue pénible, ils ont tendance à vous assassiner sur les coûts d’hébergements…
Un dernier coût d’exploitation à prévoir : la consommation de services tiers, via des API, par vos propres utilisateurs. L’exemple tendance en 2024 est l’ajout d’un chatbot GPT. Plus vos utilisateurs utilisent le chatbot, plus vous consommez de tokens Open AI et plus vous paierez une facture salée à la fin du mois.
En général, les applications de nos clients consomment peu d’API payantes, tout au plus une ou deux par projet. Lorsque c’est le cas, nous vous aidons à estimer le coût mensuel associé pour que vous puissiez l’anticiper et/ou le répercuter sur vos utilisateurs.
Maintenant que vous connaissez les 4 familles de coûts associées à votre investissement, essayons de décortiquer les différents travaux que vous financez au sein de la première famille : les coûts de développement de la solution.
Lorsque vous payez votre prestation de développement, vous n’achetez pas “du code” ou “des fonctionnalités”. Pour le bien de votre projet, vous devez vous assurer que vous financez bien plus. Voici la liste des éléments dont vous devez vous assurer auprès de votre prestataire.
Votre interlocuteur doit être un Product Owner, c’est à dire une personne dont le rôle est de comprendre les intérêts et les contraintes entre 3 parties prenantes :
Le Product Owner donne le cap de la vision produit et trouve le terrain d’entente entre tous. Le travail de conception qu’il réalise permet de s’économiser le développement de fonctionnalités qui ne seront pas utilisées et qui représentent littéralement “de l’argent, et du temps, jetés par la fenêtre”.
Le PO ne code pas, pourtant se passer de ses services est inenvisageable pour mener à bien votre projet.
En fonction de la taille de votre projet et de la cible, l’intervention d’un designer sera nécessaire. Ce n’est pas toujours le cas, notamment pour des premières versions.
Si vous avez le budget pour financer aussi un designer, bonne nouvelle. Toutefois, attention ! Le PO et le designer devront travailler main dans la main au cours du processus de conception de l’application. Mandater un designer puis venir nous voir avec des maquettes toutes prêtes est l’assurance d’un projet qui va dans le mur.
Pourquoi ?
Après plus de 30 ans de développement logiciel, la communauté des développeurs converge vers des méthodologies dites “agiles”. Elles privilégient la création de logiciels et applications par ajouts successifs d’incréments fonctionnels, au fur et à mesure des tests utilisateurs.
La rédaction d’une liste de fonctionnalités ou d’une version figée des maquettes, avant même le début du développement, est l’écueil principal que visent à éviter ces méthodologies. Règle d’or du développement : les utilisateurs ne savent pas ce qu’ils veulent, et vous non plus vous ne savez pas ce qu’ils veulent, qui que vous soyez.
Sans surprise vous achetez du développement de fonctionnalités. Quelques règles qui vous aideront à obtenir un code de qualité :
Lorsque nous développons une fonctionnalité, une bonne pratique consiste à développer un autre code qui teste régulièrement le bon comportement de cette fonctionnalité.
A quoi bon ce “double développement” ?
Les tests permettent de constater automatiquement l’introduction de régressions, c’est-à-dire l’introduction de nouveaux développements qui viendraient parasiter le comportement de fonctionnalités antérieures.
Lorsque cela arrive, et plus un développement dure, plus cela arrive, le développeur reçoit un message d’erreur qui l’empêche d’envoyer un bug face aux utilisateurs.
Une blague de développeurs dit : “Tester, c’est douter”. C’est l’équivalent de “Manger, c’est tricher” en soirée étudiante. Bref, une mauvaise idée en perspective…
L’architecture correspond, dans les grandes lignes, au découpage du code et à l’organisation des fichiers. Une organisation des plus rigoureuses est nécessaire pour que la taille du code puisse grandir ad vitam eternam.
Seulement voilà, prévoir la dimension que prendra un projet dans 6 mois, 1 an, 10 ans, n’est pas possible. L’architecture doit être en partie travaillée au fur et à mesure du projet.
Dans le jargon, on appelle cela des refactos, comprendre un refaçonnage du découpage et de l’organisation du code.
Vous me direz, quoi de plus frustrant que de payer pour la réorganisation d’un code que vous avez déjà payé ?
Ne pas passer ce “coup de balais”, c’est accumuler volontairement de la dette technique qui, le jour où elle deviendra endémique, paralysera le développement de votre solution. Désolé, mais cela fait partie des règles du jeu…
Il existe encore d’autres considérations, mais pour des raisons de technicité de l’article, je m’arrêterai là.
Vous devez vous assurer que le code développé implémente des normes de sécurité suffisantes par rapport aux enjeux de votre projet. Quelques sécurités standards :
Plus votre projet grandira, et plus il représentera une cible intéressante pour des attaquants. En effet, vous aurez de plus en plus de données utilisateurs monétisables sur le marché noir ou encore une prise d’otage de l’application permettrait d’obtenir de votre part une rançon juteuse.
C’est pourquoi, plus l’application grandit, et plus vos dépenses en sécurité, augmenteront.
Je l’ai évoqué tout à l’heure : les coûts de développement doivent représenter l’essentiel de votre investissement. Autrement dit, si vous achetez vos 20 premières fonctionnalités 20k€, n’espérez pas en achetez 100 pour 100k€. Pourquoi est-ce une bonne nouvelle ?
Plus le projet grandira, plus il y aura de travail en dehors de la “simple création de fonctionnalités”. Cette évolution des coûts doit être maitrisée mais est nécessaire : elle traduit le fait que votre équipe technique vit dans l’anticipation et non dans la réaction.
L’adage en médecine est aussi valable dans le développement : “mieux vaut prévenir que guérir”.
A travers ce long article, j’espère vous avoir démontré pourquoi le mythe de “je développe une fois, j’exploite à vie” est une utopie. En réalité, vous allez développer à vie; vos coûts seront croissants. Mais comme la rentabilité peut être exponentielle grâce à la scalabilité de l’informatique, ce type d’investissement, certes risqué, peut s’avérer incroyablement rentable.
C’est en lien direct avec la partie précédente, pourtant je me dois d’en parler. Puisque pour développer une seule fonctionnalité, plus de travail est nécessaire au fur et à mesure de l’avancement du projet, le temps entre la commande d’une fonctionnalité et sa livraison face aux utilisateurs, le “Time To Market”, augmentera nécessairement.
Cela parait évident, pourtant j’ai croisé plusieurs personnes qui refusent de le comprendre.
Ce retard peut aussi être du à de la dette technique qui grandit de jour en jour. Toutefois, ce sont souvent les mêmes personnes qui ne souhaitent pas financer des refactos et donc, qui s’enlisent dans un cercle vicieux.
A noter que l’équipe technique doit se concentrer sur le fait de maintenir ce Time To Market aussi court que possible.
C’est enfin déjà la fin de ce numéro ! 🥹
Si vous n’êtes pas abonné, il est temps d’y remédier via ce lien.
A dans 2 semaines pour un nouveau numéro sur les différents acteurs du code.
2 articles par mois sur l'innovation au coeur de votre entreprise : Tech, IA, Automatisation.
.png)
