L’activité d’investissement est en baisse maintenant, mais il est susceptible de reprendre en 2023. Et lorsque les investissements augmentent, les fusions et acquisitions augmentent également. Votre organisation et votre code réussiront-ils la vérification préalable technique lorsque ce sera votre tour ?
Commençons par les points positifs : si un investisseur procède à une diligence raisonnable technique (TDD), vous réussirez probablement. Vous avez suffisamment bien réussi les tests d’adaptation au marché des produits, de finances et de différenciation concurrentielle pour qu’ils veuillent maintenant regarder sous le capot.
Voici la moins bonne nouvelle : les entreprises peuvent réussir le test commercial, mais échouer au TDD. Surtout pour les cadres non techniques, le processus d’examen de code peut ressembler à… un audit… mené dans une autre langue… avec une horloge bruyante qui tourne sans cesse. Pas drôle.
Notre société a analysé le code de centaines de milliards de dollars de transactions, allant d’éditeurs de logiciels de trois personnes à des entreprises comptant des milliers de développeurs. Nous avons examiné les contributions de plus de 200 000 développeurs qui ont collectivement écrit 4 milliards de lignes de code.
La mauvaise santé de la base de code est le plus souvent « causée » par d’autres équipes plutôt que par l’ingénierie.
À partir de cet ensemble de données, nous avons distillé huit questions que vous pouvez vous poser maintenant. Même si TDD n’est pas à l’horizon, avoir de bonnes réponses à ces questions garantira que votre base de code est saine.
Une introduction rapide sur TDD
Avant d’aller plus loin, voici un peu plus de contexte sur la diligence raisonnable technique pour les logiciels :
- TDD s’applique aux sociétés de logiciels traditionnelles et aux sociétés non logicielles activées par des logiciels créés sur mesure.
- Cela implique l’examen du code rédigé par les employés ou les sous-traitants.
- Le TDD est réalisé par des experts internes ou par des cabinets spécialisés.
- Les investisseurs et les acquéreurs, en particulier les plus grands et les plus élites, peuvent demander à effectuer une analyse quantitative du code pour compléter les entretiens qualitatifs. Une telle analyse de code est effectivement obligatoire si l’investisseur recherche une assurance de représentants et de garanties (RWI) pour la transaction.
Les objectifs de TDD sont de :
- Dérisquer l’affaire en déterminant si la base de code est suffisamment sûre pour l’investissement.
- Identifier les opportunités d’amélioration si la transaction aboutit.
Nous disons « codebase » car c’est plus que le code source qui est sous la loupe. Votre documentation, vos processus et, plus important encore, les développeurs de logiciels seront également examinés. Le périmètre fonctionnel de TDD comprend la qualité du code, la sécurité du code, la propriété intellectuelle, le DevOps, l’informatique et, parfois, la gestion des produits.
Parce que c’est plus que la qualité du code, on parle de santé de la base de code pour englober tous ces domaines.
Question 1 : Sur quoi avez-vous travaillé ?
S’assurer que l’organisation travaille sur les produits logiciels les plus importants est un élément important de la réduction des risques de la transaction.
Cela peut sembler évident, mais parfois, une entreprise prétend travailler sur un nouveau produit, mais passera en fait la majorité de son temps sur le développement personnalisé pour des clients majeurs ou ne travaillera pas beaucoup sur quoi que ce soit.
Prenons cet exemple de développement logiciel d’une entreprise sur deux ans. Non seulement il y a une cyclicité dans le travail (plus élevée en été), mais elle a nettement diminué au fil du temps, notamment en 2022.
Crédits image : Séma
Point important : Ici, et pour toutes les questions en TDD, n’importe quelle réponse peut être suffisante pour passer l’examen.
Cela nous amène à Thème n° 1 du TDD : la partie la plus importante du TDD consiste à s’assurer que l’état de la base de code est aligné sur les objectifs commerciaux de l’organisation. Par exemple, les sociétés américaines de logiciels éducatifs voient généralement le développement de logiciels cyclique – plus élevé en été et plus bas en automne – pour minimiser les perturbations pour les clients lorsque l’école commence.
Question 2 : De combien de tests unitaires dispose votre base de code ?
Nous aimons faire la distinction entre sous-jacent la qualité du code pour inclure des mesures telles que sa maintenabilité ou sa capacité à être étendu, et la fonctionnel qualité du code — comment le produit fonctionne pour les utilisateurs.
La « dette technique » est une autre façon de décrire tout manque de perfection dans le code sous-jacent.