Si vous n'avez jamais vendu d'entreprise auparavant, vous pourriez ne pas savoir à quoi vous attendre. Souvent, l'acheteur prendra du temps pour vérifier la légitimité de votre entreprise dans un processus appelé diligence raisonnable. Pour les entreprises de logiciels, cela peut inclure un audit technique où l'acheteur, ou leur agent de diligence, tente de comprendre le fonctionnement interne de votre logiciel.

En tant que fondateur d'une entreprise spécialisée dans la diligence technique, j'ai aidé des centaines d'acheteurs à évaluer des entreprises SaaS avant de les acquérir. Je pensais que vous aimeriez savoir ce que mon équipe, et les acheteurs, recherchent lors de la diligence technique sur une startup SaaS afin que vous soyez mieux préparé à la réussir (sans maux de tête).

Pourquoi en apprendre davantage sur la diligence technique?

Pour certaines transactions, la diligence raisonnable liée à l'acquisition peut devenir un véritable cauchemar. Cochez toutes les cases. Rassemblez chaque contrat client que vous avez jamais signé. Et savez-vous où sont ces déclarations de revenus d'il y a trois ans, n'est-ce pas?

Vous traitez avec des avocats, des comptables et des investisseurs. Tous essaient de fouiller des informations que vous n'avez pas nécessaires depuis que WeWork était encore une licorne.

Et votre entreprise ne cesse pas de fonctionner simplement parce que quelqu'un veut l'acheter. La dernière chose que vous voulez en essayant de sauver un compte d'entreprise de la résiliation, c'est que je demande un "schéma d'architecture système". L'espoir est qu'avec ce guide en main, vous pourrez vous épargner des maux de tête plus tard.

Déplacez-vous rapidement sans casser les choses

Avant, lorsque les logiciels étaient emballés et n'étaient pas disponibles via les navigateurs, publier une nouvelle version logicielle pour les utilisateurs était difficile. Aujourd'hui, l'infrastructure s'est développée, et le déploiement de nouveaux logiciels ou de mises à jour peut être aussi simple que d'appuyer sur un bouton.

En tant qu'équipe de diligence technique, nous voulons comprendre à quelle fréquence votre logiciel est déployé et quel est ce processus. Avez-vous un processus qui exécute vos tests automatisés pour s'assurer que tout fonctionne toujours?

Une règle générale pour la plupart des entreprises SaaS : plus vous pouvez déployer souvent, mieux c'est. Il est bon d'avoir des systèmes et une infrastructure en place pour déployer facilement, même si vous n'utilisez pas régulièrement cette capacité.

Points clés à retenir :

• Notez votre cadence de déploiement et votre stratégie, y compris les composants techniques impliqués dans la construction du logiciel.
• Rationalisez votre processus de déploiement pour le rendre aussi simple que possible.

Ne négligez pas le "Bus Factor"

Le "Bus Factor" est une métaphore que nous utilisons dans le logiciel pour évoquer le risque de perdre des membres clés de l'équipe ayant des informations vitales. L'idée : si un membre clé de l'équipe était percuté par un bus demain, son travail pourrait-il être repris de manière fiable ? Triste, je sais. Mais en réalité, beaucoup de connaissances résident uniquement dans la tête des gens.

Au début, l'acheteur sera la personne la moins informée dans l'entreprise, ce qui signifie qu'il aura le moins de poids en ce qui concerne le risque lié à une personne clé. Pour atténuer cela, l'une des choses que nous recherchons est la documentation technique. En plus de servir de protection contre la concentration des connaissances, elle accélère le processus de diligence en permettant de jeter un coup d'œil sur le système sans avoir besoin de lire chaque ligne de code. Et si l'acheteur a des plans ambitieux pour le produit, il peut vouloir ajouter de nouveaux talents à l'équipe.

Points clés à retenir :

• Rassemblez toute la documentation technique utile dans un endroit centralisé où il est facile de la trouver.
• Si vous n'en avez pas déjà un, demandez à votre équipe de développement de créer un manuel d'intégration détaillant comment un nouveau développeur pourrait se mettre à niveau. Cela devrait inclure tout, de l'architecture générale à la configuration d'un environnement de développement local.

Surveillez ces bogues

Votre équipe vient de lancer une version majeure. Tout le monde célèbre. Puis les rapports de bogues commencent à affluer. Une partie de l'application cesse de fonctionner. Le flux d'intégration ne envoie pas d'e-mails. Vos développeurs ne cessent de parler de l'augmentation de la profondeur de la file d'attente, et vous n'êtes pas sûr à 100 % de ce que cela signifie, mais vous pouvez dire que ce n'est pas bon.

C'est un fait connu : tous les logiciels ont des bogues. Malheureusement, nous vivons dans le monde réel et ne pouvons pas écraser chaque bogue dès qu'il apparaît. Nous avons des contraintes et des feuilles de route produits. Mais pour l'amour de tout ce qui est sacré, veuillez consigner vos bogues dans un outil de suivi avec des descriptions et des étapes reproductibles.

De nombreux outils de suivi de bogues automatisés s'intègrent directement à votre code source. Si aucun ne convient à votre entreprise, tout logiciel de suivi de tickets (par exemple, Trello, Jira, Notion) fera l'affaire. Ce qui est le plus important, c'est que vous ayez quelque chose et que vous l'utilisiez.

Points clés à retenir :

• Tenir un registre des bogues démontre une sophistication dans votre processus produit et assure à l'acheteur que vous êtes en contrôle.
• Si possible, utilisez un logiciel de suivi des bogues qui peut avertir automatiquement des interactions inattendues de l'utilisateur. Idéalement, cela devrait également inclure les étapes pour reproduire.

Laissez des indices de code

Les logiciels évoluent. Les exigences commerciales changent. Les clients veulent de nouvelles choses. Les bogues sont corrigés. Tous ces changements affectent votre base de code et contribuent à former un récit. Les meilleures pratiques modernes dictent l'utilisation d'un système de contrôle de version pour suivre les modifications apportées à votre code source. C'est bénéfique pour quelques raisons :

• Vous pouvez suivre qui a changé quoi et quand. Si je veux comprendre quels fichiers ont été modifiés pour mettre en œuvre une fonctionnalité, je vais examiner le journal de contrôle de source.
• Il existe plusieurs copies des fichiers de code source disponibles, au cas où des modifications seraient perdues. Généralement, les équipes de logiciels synchronisent leurs modifications de fichiers via un service centralisé comme Github ou Gitlab.

En pratique, la plupart des équipes de développement font déjà cela, donc cela devrait être facile à vérifier.

Points clés à retenir :

• Assurez-vous de suivre les modifications de code dans un système de contrôle de version, de préférence Git. Plus tôt vous commencez à suivre, mieux c'est.

Sécurisez votre système

La sécurité est un énorme sujet, et un compte rendu détaillé de toutes les meilleures pratiques dépasse le cadre de cet article. Cependant, il y a quelques fruits extrêmement bas que vous devriez traiter, la plupart d'entre eux tournant autour du processus.

Gardez les secrets

Comment votre équipe stocke-t-elle les informations d'identification? Y a-t-il des secrets extrêmement sensibles qui circulent dans les canaux Slack? Quelqu'un a-t-il accidentellement copié le mot de passe de la base de données dans le contrôle de source? Vous voudrez vous assurer que ce genre de choses est sécurisé. Pour partager des secrets, utilisez un gestionnaire de mots de passe partagé ou quelque chose qui prend en charge les messages chiffrés comme Keybase.

Accès confidentiel

Un des principes fondamentaux de la sécurité est le principe du moindre privilège : une personne/programme doit avoir toutes les informations dont elle a besoin pour faire son travail, mais rien de plus. En pratique, cela signifie s'assurer que les membres de l'équipe n'ont pas un accès ou des privilèges inutiles. Un membre de l'équipe du support client a-t-il besoin des informations d'identification de la base de données de production? Non.

Maintenance de la chaîne d'approvisionnement logicielle

À la fin de 2021, une vulnérabilité de sécurité d'ampleur épique a été divulguée. Surnommée "Log4Shell", elle permettait à des attaquants malveillants d'exécuter un code arbitraire en manipulant des messages journaux. Les plus grandes entreprises Internet du monde étaient concernées, y compris Amazon et Google. Heureusement, la communauté open source a pu rapidement publier des correctifs qui atténuaient l'exploitation. Malheureusement, il existe toujours des systèmes vulnérables en circulation qui n'ont pas été mis à jour. Suivre les dépendances de votre application et les maintenir à jour est important pour construire un programme de sécurité robuste.

Points clés à retenir :

• Utilisez des systèmes sécurisés pour gérer et transmettre les informations d'identification. Effectuez un audit pour vous assurer qu'aucun secret n'est exposé.
• Gardez à l'esprit le principe du moindre privilège, limitant l'accès aux systèmes lorsqu'il n'est pas strictement nécessaire.
• Établissez un programme de gestion des dépendances pour rester en avance sur les mises à jour de sécurité cruciales. En exemple, consultez le système Dependabot de Github.

N'oubliez pas la fiabilité

Assurance base de données

La plupart des applications utilisent une base de données de quelque sorte, qu'il s'agisse d'une base de données relationnelle ou d'un magasin NoSQL. Un des plus grands facteurs de risque que nous recherchons lors de la diligence est de savoir s'il existe des instantanés récents de la base de données et à quelle fréquence ces instantanés sont pris. Les sauvegardes sont comme une assurance. Vous espérez ne jamais avoir à les utiliser, mais c'est vraiment bien qu'elles soient là quand vous en avez besoin.

Rapports d'incidents

Il est courant que les applications connaissent des périodes d'indisponibilité. Lorsque cette indisponibilité est significative et a un impact matériel sur l'entreprise, la création d'un rapport d'incident, ou d'un post-mortem, est importante. Idéalement, ce document élabore une analyse des causes profondes de l'indisponibilité et suggère des ajustements pour éviter le même type de problème à l'avenir. Avoir une liste des principales interruptions au cours de la dernière année donnera à un acheteur potentiel l'assurance que vous dirigez une organisation proactive.

Points clés à retenir :

• Assurez-vous que vos bases de données sont sauvegardées automatiquement.
• Gardez une liste de toutes les interruptions de service et des remédiations ultérieures mises en place. Voici un bon modèle de départ.

Gardez la maintenance à l'esprit

Dette technique

Avez-vous, ou votre équipe, déjà pris un raccourci technique pour livrer une fonctionnalité plus rapidement? Avez-vous ce flux dans votre application que vous savez être un peu bancal mais que vous avez reporté à plus tard pour le réparer ? Notez cela quelque part. Idéalement, cela devrait figurer sur une feuille de route produit ou technique formelle avec une correction planifiée, mais même un document Google fera l'affaire.

Être transparent avec un acheteur potentiel au sujet des lacunes produit va loin pour établir la confiance et rendre la transaction plus fluide. Certains éléments de dette technique sont plus complexes que d'autres, donc s'il est particulièrement délicat, il est acceptable de différer le plan de mise en œuvre réel.

La division entre fonctionnalité et maintenance

Combien de temps de votre équipe de développement est consacré à la maintenance par rapport au développement de nouvelles fonctionnalités? Si une grande partie du temps de l'équipe est consacrée à la maintenance, cela pourrait indiquer des problèmes sous-jacents de qualité de code ou d'architecture. En même temps, il est bon de voir que l'équipe rembourse la dette technique au fil du temps. En gros, l'équipe devrait consacrer de 10 à 20 % de son temps à corriger les bugs et à améliorer l'architecture sous-jacente.

Points clés à retenir :

• Documentez toutes les dettes techniques ou produit. Si possible, incluez une implémentation approximative ou une stratégie pour y remédier.
• La dette technique vraiment compliquée n'a pas besoin d'inclure un plan de remédiation, mais elle doit être mentionnée.
• Il est idéal de voir l'équipe technique consacrer 10 à 20 % de son temps à travailler sur des améliorations techniques.

Êtes-vous prêt pour la diligence technique?

Vous venez de faire un tourbillon à travers certaines des choses les plus utiles que vous pouvez faire pour préparer votre entreprise logicielle à la vente. Malgré l'étendue du matériel que nous avons couvert, il y a encore beaucoup de choses que nous n'avons pas abordées. Il y a la scalabilité, l'architecture système, les tests automatisés, et peut-être le plus intrigant de tous, les coûts d'infrastructure. Nous devrons aborder ces sujets une autre fois.

Encore une fois, l'espoir est que vous puissiez vous épargner beaucoup de maux de tête en abordant ces éléments tôt, afin que, lors de la diligence, vous puissiez dire : "Oh oui, j'ai lu un excellent article sur Alvo.market qui m'a donné tout ce dont j'avais besoin".

Eh bien, peut-être que ce ne sera pas aussi facile. Mais lorsque vous serez à la table des négociations et que la seule chose qui vous sépare de votre tour de victoire est quelqu'un comme moi implorant de "voir votre sprint burndown", j'espère que cela vous donnera un avantage.