Relation et opinion sur la dette⌗

Cet article évoque des sujets sur la finance. Dans tous les cas, cet article n’est en rien un conseil, ni une guideline pour gérer votre portefeuille d’actions. Le contenu est uniquement centré sur une idée que je veux exprimer. Ne prenez pas de décision financière sur base de cet article.

La majorité de mon entourage a une opinion négative de la dette. Une vision comme étant un poids à éviter à tout prix. Pourtant, la dette est un outil financier, qui peut être utilisé pour créer de la richesse. Il suffit de regarder les entreprises, qui utilisent la dette pour financer leur croissance.

La dette technique est directement inspiré de la dette financière. Je vais tenter d’expliquer en quoi ces 2 types de dettes sont liés, et tenter donner une contre opinion que la dette n’est pas forcément mauvaise. La seule chose à éviter est une dette hors de contrôle, autrement appelé le surendettement.

Aussi, vous apprendrez que mettre de côté son amour pour le beau code pour le développement d’une entreprise. Aujourd’hui, on pense comme un investisseur ou un financier.

C’est quoi une dette ?⌗

En finance, une dette est une obligation de rembourser une somme d’argent à une date donnée. Les particuliers ont recours avec un format communément admis en Belgique : chaque mois, nous remboursons une partie du capital, et avec un coupon, qui est un surplus au bénéfice du prêteur. Ce format a pour avantage que même les profils les moins prévoyants puisse rembourser sa dette, sans perdre le contrôle et prévoyant mal le remboursement du capital. C’est un format désavantageux mathématiquement parlant, mais avantageux pour le comportement humain.

Les entreprises ont accès un autre format de dette : donner fréquemment un coupon au prêteur, et après une date définie, rembourser tout le capital d’un coup. Lorsque la date fatidique arrive, plusieurs actions sont possibles :

• Rembourser le capital
• Refinancer la dette
• Une partie des deux

Le refinancement est une opération qui consiste à contracter une nouvelle dette pour rembourser la dette existante. Cette opération très courante en finance d’entreprise, permet de réduire le coût de la dette, de modifier les conditions de remboursement, de profiter de taux d’intérêt plus bas ou d’assurer un cash minimum disponible pour tout autre raison. Bref, sans rentrer dans le détail, c’est courant. Et c’est ce format que prend la dette technique en informatique.

Les entreprises font faillite majoritairement, car elle n’arrive pas à refinancer leurs dettes. Le management ayant prévu de refinancer comme d’habitude, il suffit que quelques mauvaises nouvelles s’entasse au mauvais moment pour qu’une entreprise tombe en faillite. C’est comme ça que LTCM, entreprise financière qui avait un rendement de dingue se retrouve en faillite. Plus d’info sur la chaine Heu?reka.

Ici quelques exemples des gestion de dette StarBucks est l’entreprise la plus endettée et qui survie que je connaisse. Elle cumule 29,5 milliards de dollars de bien (commerce, machines, image de marque, cache, vente en avance, inventaire) et 37,4 milliards de dollars de dette. Ce qui signifie que l’entreprise à plus de dette que de bien, situation rare en finance. Starbuck fait aujourd’hui suffisamment de bénéfice pour négocier un refinancement et faire exception. Même si la dette est énorme, j’imagine que les banques acceptent grâce à une revenue stable et continue. Un autre exemple, Winnebago Industries est un exemple explicite du refinancement. Elle n’emprunte ni plus, et ne rembourse pas le capital.

L’effet de la dette constamment refinancer n’a donc pas d’effet sur le capital disponible. Le capital étant soit utilisé dans le développement de l’entreprise, soit pour garder du cash et réagir aux événements, ou encore renflouer son inventaire après la sortie du dernier modèle du produit vendue par la compagnie. L’effet de la dette, ici appelé coupon, s’applique sur les bénéfices. À devoir payer un coupon fréquemment, l’entreprise ampute une partie des bénéfices. Tout le jeu d’un bon financier, est de déterminer si le remboursement de la dette est plus efficace que de profiter d’opportunité de marché. L’équilibre est de savoir si le capital est utilisé efficacement en diminuer les ‘dépenses’ des coupons en remboursant la dette, ou bien de conserver la dette, car le capital dédié aux opérations a un effet plus bénéfique que le remboursement. C’est exactement ce point qui sera discuté dans la suite de l’article.

Dette technique, exemple extrême de la startup⌗

La dette technique est similaire. À un moment donné, un raccourci est pris. Quelques tests en moins, de la logique dans la mauvaise couche pour vite corriger un bug en dehors du sprint, une fonctionnalité urgente à livrer avant la période de Noël avec un design fragile, une première version d’une application a vite livrer sous forme d’expérience, etc. Livrer un déployable aussi vite que possible est courant, et parfois pour des bonnes raisons.

Bien sûr, la dette peut apparaitre par accident si des mauvais choix de designs ont été faits, n’ont pas été reconnus et refactorer en mode YAGNI. Mais qu’elle soit d’origine accidentelle ou volontaire, le choix de garder la dette, ou de la rembourser est la même.

La dette technique est un outil. Comme la dette financière, elle peut être utilisée pour créer de la richesse. Par exemple, une startup qui a besoin de livrer un produit rapidement pour tester le marché, peut se permettre de prendre des raccourcis pour livrer plus vite. Une entreprise qui a besoin de réagir rapidement à un changement de marché, peut se permettre de livrer un déployable avec des tests en moins. Une entreprise qui a besoin de livrer une feature rapidement pour garder un client, peut se permettre de livrer une feature avec un design fragile. Une fois que le produit est sur le marché, 2 scénariis sont possibles :

• Le produit ne prend pas. Le produit peut être jeté, et imposer la dette technique était purement bénéfique. Faire ‘faillite’ avec un minimum d’investissement est rationnellement le meilleur choix. C’est l’équivalent de faire faillite et de ne pas rembourser la dette.
• Le produit trouve sa place, il y a de la demande. La dette a servi à prouver que le produit fonctionne.

Prouver la viabilité d’un produit se fait pendant la phase startup. Un bon marketing permet d’attirer les premiers profils. Un bon produit permet de déclencher le bouche-à-oreille, et bénéficier d’un autre segment de marché. Plus d’information sur le marketing de produits software avec le livre Crossing the Chasm, 3rd edition (Geoffrey A. Moore, 2014) si la curiosité vous pique.

Le premier scénario signe la fin de l’aventure, explorons uniquement le deuxième.

La startup a prouvé que le produit est bon, il est maintenant nécessaire de passer en seconde phase. Et… La tentation de continuer de payer avec de la dette est grande. À ce moment, l’objectif du business est de faire grossir la base de consommateur ou d’utilisateur dans le cas de logiciel. C’est une étape où il est difficile d’identifier quel est le bon niveau de dette. Il est important de viser une certaine croissance, qui peut-être payé avec une dette. Mais aussi, la durabilité devient une dimension importante du développement.

En dernière étape, quand le business n’est plus capable de faire grossir sa base d’utilisateur, elle entre en 3e phase. C’est ici qu’il est temps non plus d’être attractif sur les marchés, mais d’optimiser les opérations, appliquer des prix optimaux, changer sa stratégie pour stabiliser le revenu. Le développement devient limité, c’est généralement à cette étape qu’il est optimal de rembourser les dettes passées.

Pour Netflix, il s’agit d’appliquer des prix optimaux. Tant que la base utilisateur augmentait, autorisé des partages de mot de passe est en accord avec les principes de croissances. Mais une fois la limite atteinte, optimiser les prix sur chaque utilisateur devient la priorité. Pour Prime Vidéo, il s’agit de changer l’architecture de l’application. L’architecture précédente était idéale pour un développement rapide. La nouvelle architecture est plus résistante au changement, mais diminue les couts d’infrastructure. Pour Redis, il s’agit de s’accaparer des parts de marché pris par les Cloud providers sur les formats Redis as a Service en appliquant une licence RSALv2 et optimiser les revenues.

Situation idéale⌗

L’exemple ci-dessus de démarrer un produit avec une grande partie de dette est extrême. La réalité est autre, il y a un équilibre. Si le développement devait uniquement se reposer sur des anti-patterns, nous aurions un autre problème : le surendettement. User exclusivement de la dette pour financer le développement est impossible à tenir sur le long terme. Dans le cas financier, le développement peut se financer avec du nouveau capital avec un appel aux investisseurs, ou avec une IPO. Mais qu’en est-il d’un projet informatique ?

La dette peut être utilisée comme un outil qui doit trouver un équilibre et être usé en situation judicieuse. Cet article ne doit pas servir d’excuse pour produire une base de code de faible qualité au nom d’une dette intelligemment utilisé. Par expérience personnelle, même une application qui prend moins de 2 semaines à développer à un bénéfice à avoir des tests unitaires.

C’est ici que les bonnes pratiques de développement entrent en jeu. Non qu’il faut toutes les appliquer à tout moment, mais que chaque investissement en pattern soit correctement appliqué. La difficulté est de reconnaitre quand les appliquer.

Ce que je recommende, est une série de questions qui peut vous guider dans ce cadre de choix difficile.

• Est-ce que je fais du YAGNI ? Est-ce que je suis en train de résoudre un problème d’aujourd’hui, ou un problème de demain ? Est-ce que le code est facile à refactorer et est-ce que les units tests me protège en cas de refactoring (Il y aura un article spécifiquement sur YAGNI et le refactoring just in time. Plus tard).
• Est-ce que l’architecture me permet de faire des choix qui me bloque à un design unique ? Puis-je appliquer un choix de design qui me permet de faire des choix difficiles le plus tard possible ?
• Est-ce que je suis vendor-lock ? Est-ce que je dépends directement du bon vouloir d’un fournisseur, et si oui, est-ce durable et est-il fiable ?
• Dois-je vraiment négocier l’écriture de test unitaire avec le management ? N’est-ce pas une pratique indivisible du développement ? (c’est une question réthorique 😄)
• Est-ce que des filets de sécurités sont installés comme un monitoring actif, des procédures répétables et indempotent, un déploiemement automatique et automatisée, des déploiements de type canary sont permis, y-a-t’il un environnement d’acceptance pour valider le développement, etc.

Et le beau code dans tout ça ?⌗

Pour ceux qui m’ont connus entre 2018 et 2022, cet article peut vous étonner. Comme annoncé en intro, permettre de la dette technique m’était inconcevable. J’ai changé. J’ai compris que le beau code n’est pas une fin en soi. La dette technique n’est pas un mal en soi. C’est un outil qui permet de créer une application rapidement au détriment de la durabilité. Comme la dette financière. Tout le jeu est de trouver l’équilibre à chaque phase de vie de l’entreprise.

Il est donc normal de trouver du code ‘honteux’ dans les startups et du code ‘élégant’ dans les entreprises établies. Toutefois, n’oubliez pas le problème de faillite possible en cas de surendettement. Tout ne doit pas tomber sur un cycle de développement en dehors des bonnes pratiques de développement sous argument que le marché se développe. Il y a un équilibre, et trouver cet équilibre est aujourd’hui la partie la plus difficile de mon métier.

Il m’arrive fréquemment de voir en code revu du code qui me déplait à cause de détail, ou bien parce que le CPU sera mis sous stress un tout petit peu plus. Mais juste prendre le temps de commenter ’tiens, un retour à la ligne ici rend le code plus lisible’, ou bien ‘favoriser cette technique fera gagner quelques cycles de CPUs’ à un retour sur investissement positif après des dizaines d’années. Pour du style, il est plus efficace de le réparer au moment où l’on le relit dans le cadre d’un développement ultérieur au lieu de devoir garder tout impeccable à tout moment.

Mon plaisir existe encore dans la production de code élégant, mais n’est plus mon seul objectif. Trouver une balance entre les deux est une capacité que je développe de jour en jour, et dont je remettrais de temps à autre les fondamentaux.

Broken Window Effect⌗

Une mise en garde toutefois destiné aux manageurs. L’usage de la dette est un outil rationnel, mais la dette technique a un effet psychologique. Ça n’est pas gratifiant de forcer trop fréquemment les raccourcis. Il est important de garder les développeurs à la fois motivé, mais surtout engagé dans leur travail. Une base de code trop ou des pratiques en décalage avec les convictions personnelles démoralise méchamment, augmente les turnovers, apporte de l’absentéisme et des comportements inefficaces. Nous n’avons exploré que la partie rationnelle de la question. Les conséquences comportementale et sociale n’est pas à sous-estimer. Il devrait être normal que tout humain accepte un décalage léger entre les valeurs personnelles et d’entreprise, mais un décalage trop grand apporter un désengagement fort chez les travailleurs. Ne sous-estimez pas cette dimension.

Autres sujets pêle-mêle⌗

Le contenu de l’article étant établis, les sujets restants sont des idées que je veux partager, mais qui n’avaient pas de place précédemment. Voici une ensemble de sujet que je souhaite aborder à propos de la dette technique.

L’échelle de la dette⌗

Avoir une variable mal nommée peut s’apparenter à un prêt dont le coupon est à 0,01% par an. Facilement remboursable avec la règle du boy scout (nettoyez le code quand vous travaillez sur d’autres sujets). Une base de code sans tests unitaires est équivalente un prêt à 45% an. C’est vivable en début de projet, mais qui demande à être remboursé le plus vite possible pour éviter un surendettement, car les 45% seront toujours à la hauteur de l’avancement du projet. La viabilité du projet deviendra rapidement insoutenable.

Code is a liability⌗

Vous avez peut-être entendu cette expression. Elle exprime que chaque base de code est une dette. Même avec un design parfait, des pratiques optimales, et des tests de qualité, le code sera toujours une dette. Ces 3 éléments cités permettent de la garder sous-contrôle, comme si les appliquer permet de passer d’une dette de 35% à une dette à 5%. Mais une dette quand même.

La dette technique et open source⌗

Je ne me souviens plus de l’auteur du principe qui suit, mais elle n’est pas de moi.

Une entreprise paie avec de l’argent, un projet communautaire open source paie avec du temps. Lorsqu’un développeur passionné partage un projet open source, sans modèle économique, alors il paie le développement de son temps.

L’énoncé est simplifié, il peut arriver qu’un projet d’entreprise prenne le format avec licence open source. Elle est donc au final payé avec de l’argent plus que du temps. Et aussi, dans un cas d’un projet d’entreprise, le développement prend du temps. Et vous savez bien que le temps, c’est de l’argent.