Si vous envisagez l’achat d’une société dont une partie significative des actifs est constituée de codes sources, vous devez être en capacité d’estimer leurs valeurs. L'évaluation de ces actifs peut vous aider à identifier les risques potentiels induits par l’existant technique et à mesurer la valeur réelle de l'entreprise.
Cet article vise à introduire les risques principaux lors de l’achat d’un SaaS. Nous apprendrons aussi à détecter les indices qui peuvent vous mettre la puce à l’oreille.
Cependant, si votre intention d’achat est réelle et que vous n’êtes pas développeur confirmé, vous devrez réaliser un audit des solutions techniques par un professionnel.
Cet article s’appuie sur notre méthodologie d’audit. Pour plus d’informations, voici une étude de cas sur le sujet.
Bonne lecture !
L’objectif d’un audit technique est de mesurer la dette technique accumulée par l’entreprise sur les solutions développées. Mais de quoi s’agit-il ?
Définition : La dette technique est une dette financière contractée en échange de vélocité ou à cause de mauvais choix techniques. Tout comme pour une dette financière classique, l’entreprise ayant contractée une dette technique devra payer des intérêts et finira inévitablement par rembourser sa dette.
Plus concrètement, il est fréquent qu’un développeur “laisse du bazar” derrière lui soit parce qu’il souhaite accélérer un développement, soit parce qu’il ne se rend pas compte qu’il ne procède pas de la bonne façon.
Ce “bazar”, s’il n’est pas vite corrigé, ralentira les prochains développements. Au début, la gêne sera à peine perceptible. Plus tard, la dette risque de s’accumuler de manière exponentielle jusqu’à rendre l’équipe de développement presque immobile. Voici un schéma qui illustre parfaitement ce phénomène.
Comment estimer le coût des intérêts et du remboursement ?
Intérêts : Durée de développement supplémentaire nécessaire pour développer une fonctionnalité par rapport à un scénario de développement idéal.
Remboursement : Durée de réusinage nécessaire pour revenir à un scénario de développement idéal.
Il n’est pas rare de découvrir des entreprises n’ayant jamais remboursé leur dette technique. Attention, leurs codes sources sont de véritables bombes à retardement…
Voici une rapide description des 4 sources possibles de dette technique, classées par ordre d’importance.
Le choix des technologies est le premier élément à considérer lors d'un développement. Les technologies choisies peuvent avoir un impact significatif sur la vitesse de développement, la performance et l’évolutivité d’une application.
En règle générale, plus une technologie est adoptée par une large communauté de développeurs, et si possible avec une courbe d’adoption en croissance, plus elle est pertinente.
Si le choix d’une technologie est source de dette technique, vous devrez la remplacer par une technologie plus adaptée et réécrire tout le code lié de près ou de loin à cette technologie. C’est un travail terriblement long.
Comment savoir si le SaaS que j’achète est basé sur de bonnes technologies ?
Demandez la liste des technologies utilisées à l’équipe technique. Plus il y en a dans la première liste, plus c’est bon signe. Et inversement avec la seconde liste. Attention, ces technologies n’est pas exhaustive.
Technologies “adoptées”
Technologies “dépréciées”
La seconde source de dette technique la plus impactante est la conception des architectures, c’est à dire la façon dont le code a été structuré et organisé. Moins l’organisation est claire, plus le code s’apparente à un sac de noeud et plus il sera difficile de réaliser des modifications ou des ajouts. Dans les cas les plus extrêmes, nous parlons de code spaghetti.
Nous ne nous étendrons pas sur cette partie car seul un développeur est en capacité d’apprécier la qualité de l’architecture d’un code. Vous ne pourrez pas le faire vous même.
Retenez simplement que démêler un sac de noeud de sorte à passer d’un code sans réelle architecture à un code à l’architecture rigoureuse demande à minima des semaines de travail.
La troisième source de dette technique provient de la qualité du code en lui-même, c’est à dire à quel point le “langage est maitrisé par le développeur”. L’outil SonarQube permet de réaliser un scan de votre code source afin d’en estimer la qualité. Il mesure plusieurs critères et impose, par défaut, les standards suivants :
Voici 2 analyses illustrant des situations aux opposés en terme de dette technique. Pour information, SonarQube estime à 200 jours de travail le temps nécessaire pour régler la dette technique associée à la qualité du code.
Avant de mandater un auditeur, vous pouvez demander aux équipes de développement de la société que vous souhaitez racheter de réaliser un scan SonarQube. Vérifiez bien qu’ils vous envoient la vue “Overall Code” et non “New Code”, autrement SonarQube analysera uniquement la qualité du dernier ajout dans le code et non le code dans sa globalité. Demandez leur également la vue mesurant la quantité de travail nécessaire pour résoudre les problèmes détectés.
Ps: si l’équipe de développement ne sait pas comment réaliser le scan, c’est mauvais signe 😉
Pour terminer, il reste une dernière source de dette technique : la qualité de la documentation technique fournie avec le code.
Contrairement aux idées reçues, un développeur ne lit pas du code comme un traducteur lirait une langue étrangère. Il doit comprendre les logiques développées, c’est à dire le rôle de chaque algorithme, les données qu’il prend en entrée et celles qu’il génère en sortie. Pour cela, il peut s’appuyer sur plusieurs documents :
L’absence de documentation peut avoir un impact important. Un nouveau développeur devra réaliser beaucoup de retro engineering sans elle. Toutefois, cette source de dette technique peut être réglée rapidement (quelques jours maximum) par les concepteurs du code source.
Voici une liste non exhaustive d’autres problèmes, faciles à détecter, qui vous permettront d’apprécier la qualité des solutions techniques que vous envisagez d’acheter. Ces problèmes appartiennent aux 4 catégories précédentes mais nous préférons les lister ici pour une meilleure compréhension :
L’expert que vous mandatez devra auditer les actifs suivants :
Pour chaque actif audité, votre expert devra vous remettre une grille d’évaluation de l’actif afin que vous ayez une sorte de photographie de l’existant technique que vous achetez.
A l’issue d’un audit technique, 3 conclusions sont possibles :
Le scénario 3 semble catastrophique et pourtant, il ne l’est pas forcément. C’est une mauvaise nouvelle certes, mais pas au point de bloquer le rachat. La réécriture d’un code source est un passage obligatoire pour certaines entreprises. Par exemple, Uber explique dans son blog tech avoir réécrit chaque partie de son code source, entre 2014 et 2017.
La valeur d’une entreprise commercialisant un SaaS réside dans l’ordre :
Une réécriture totale n’impacte pas les 2 premiers points. De plus, une réécriture basée sur des technologies modernes et ne nécessitant pas d’exploration des besoins utilisateurs (l’entreprise connait ses clients et sait précisément ce dont ils ont besoin) est assez rapide. Il est possible de réécrire 10 ans de développement en 1 ou 2 ans.
La réécriture totale des codes sources a certes un coût financier important, mais vous êtes loin de “tout jeter à la poubelle”. A l’inverse, ne pas racheter l’entreprise et “reprendre le développement de 0”, n’est pas une si bonne idée car vous vous privez des 2 premiers points ci-dessus.
En conclusion, si l’entreprise possède des codes sources développés sur mesure, vous devez les faire auditer.
L’audit réalisé doit vous permettre de comprendre :
Rappelez-vous que vous n’achetez pas qu’un existant technique : vous achetez avant tout une base clients et des équipes.
Besoin d'auditer un code source ? Contactez-nous, nous pouvons-vous aider.
2 articles par mois sur l'innovation au coeur de votre entreprise : Tech, IA, Automatisation.
.png)
