Loading...Pour les CTO, bien comprendre le coût total de possession (Total Cost of Ownership en anglais) des produits digitaux doit être vu comme un impératif stratégique essentiel à la prise de décisions commerciales saines.
L’une des plus grandes difficultés pour définir le rôle du CTO tient au fait que les responsabilités qui le caractérisent n’ont pas non plus de définitions simples. Le rôle du CTO est né au sein des fonctions R&D au cours des années 1980 afin de s’assurer du bon alignement de ces investissements avec la stratégie.
La mission du CTO avait pour but initial de veiller à ce que les activités R&D alimentent la stratégie commerciale. Ce rôle n’était manifestement pas prévu à l’origine pour les petites organisations. Bien entendu, la stratégie n’est pas un concept aisé : plus nous la détaillons, plus elle s’obscurcit.
Le coût total de possession (TCO), qui devrait pourtant se trouver au cœur de la stratégie, est toutefois un concept par trop souvent négligé. Cet article divisé en deux parties dans le but de couvrir le sujet aussi amplement que possible tente donc de mettre enfin en lumière cette idée critique pour l’entreprise.
Qu’est-ce que le coût total de possession ?
Le coût total de possession évalue les dépenses associées à l’achat, au déploiement, à l’utilisation et au retrait final d’un produit ou d’un équipement. Le TCO inclut donc le prix total du cycle de vie complet du produit, de l’innovation à la scalabilité et tout ce qui s’ensuit. De ce fait, il constitue une base plus précise pour déterminer la valeur d’un investissement que le seul prix d’achat.
La stratégie du CTO n’a de sens que si elle implique une analyse coût-avantage ainsi qu’une analyse du retour sur investissement. De ce point de vue, le TCO couvre l’analyse coût-avantage, mais la pousse encore plus loin en veillant à ce qu’il n’y ait aucuns frais cachés et que les coûts entiers soient visibles des décideurs une fois que le produit voit le jour et mûrit.
Pourquoi le TCO est-il important pour les CTO ?
Les logiciels constituent l’activité, ou tout au moins une très grande part de l’activité, d’une entreprise numérique. De ce fait, les services et produits sur lesquels travaillent les CTO font partie intégrante de la valeur d’une société (cotée ou non) qui couvre toutes les facettes de l’entreprise, notamment sa gestion, la structure de son capital et ses futurs bénéfices. Ce que les CTO et les équipes qu’ils dirigent font avec la technologie accroît ou réduit la valeur de l’entreprise.
En tant que CTO en exercice, j’ai participé à de nombreuses opérations de due diligence technique. Chaque fois que nous examinions les choses de plus près, les vendeurs avaient un choc en découvrant pour la première fois comment tout s’ajoute dans le TCO. Dans la vie de toute entreprise, il y a généralement un moment où la phase suivante nécessite une due diligence technique approfondie. Il est possible de mieux s’y préparer.
Il est facile de deviner ce qui se passe quand on néglige le TCO :
- Le prix de vente et la valeur d’une entreprise peuvent changer en raison de problèmes révélés dans le cadre de la due diligence.
- Un acheteur peut demander une garantie pour risque élevé de perte de réputation (les activités de sécurité ont été négligées).
- L’acheteur peut même annuler une procédure d’acquisition (systèmes d’information hors de contrôle).
- Remplacement du CTO à l’issue de la transaction (positionnement inadéquat).
Bien entendu, le TCO est utile dans de nombreuses situations commerciales et est fondamental dans les secteurs industriels et manufacturiers. Dans cet article cependant, lorsque nous parlons de TCO, c’est aux produits digitaux que nous pensons.
Types d’estimations de coûts incluses dans le TCO
Pour résumer, il faut intégrer tous les coûts au TCO, même si certains de ces coûts sont indirects. Voici quelques exemples pour le développement (et non l’acquisition) de produits digitaux :
- Développement (incluant la gestion d’équipe, le product ownership, l’assurance qualité, le DevSecOps)
- Dette technique (un concept simple soulevant de nombreuses questions pour les CTO. Mal gérée, elle peut facilement conduire à une complexité insoutenable et à d’importantes pertes de compétitivité).
- Inadéquation de la stack technologique (choix de solution inapproprié)
- Licences et outils
- Infrastructure exploitée
- Support et maintenance
- Gestion des incidents
- Brèches de sécurité (en perte de réputation et coûts de restauration)
- Continuité de l’activité et reprise après sinistre
- Conformité réglementaire
- Audits
- Formation (+ intégration continuelle de nouveaux utilisateurs)
- Gouvernance
- Mise hors service
L’équation du TCO
Évaluer le TCO n’est pas sorcier, mais ce n’est pas si simple pour autant. Le schéma ci-dessous est un modèle que j’ai créé pour travailler sur les évaluations de TCO avec mes équipes. Comme bien souvent, il est le fruit de nombreuses itérations.
Coûts d’évolution du produit
Les coûts d’évolution d’un produit sont parfois appelés coûts d’acquisition ou coûts initiaux. Si vous développez vous-même un produit digital ou que vous l’achetez, ces coûts sont intégrés ici. Ce terme signifie donc plus qu’« acquisition ».
Même si l’organisation crée et optimise activement la valeur créée, des coûts sont générés.
Les licences des développeurs pour les IDE entreraient par exemple dans ce cadre. Leur package salarial aussi. Et s’agissant des salaires, comme le TCO est en général évalué sur trois ans, leur évolution compte aussi. Peu importe que le produit existe ou n’en soit encore qu’à ses débuts avant le lancement du MVP.
La dette technique estimée s’ajoute ici aussi. L’amélioration du produit via le DevSecOps, la conformité aux nouvelles réglementations et les pratiques d’ingénierie (pour améliorer la qualité ou réduire la durée du cycle, augmenter les capacités de l’architecture ou toute autre activité de performance) se greffent également ici, car elles impliquent toutes une évolution du produit.
Vous vous demandez sûrement pourquoi l’inadéquation de la stack technologique n’entre pas dans la dette technique. En réalité, elle peut sauf si elle est suffisamment importante pour être recensée séparément.
Coûts de l’évolution du produit vs coûts de maintenance
Beaucoup d’entreprises distinguent les coûts associés à l’évolution du produit de ceux liés à sa maintenance. Pourquoi ? Dans le cas de l’achat, l’acquisition s’accompagne aussi de services de maintenance qu’on peut souhaiter voir apparaître sur des lignes différentes. Dans le cas du développement, les organisations sont structurées de manière à faire passer un travail du statut de « développement actif » à « maintenance ».
Partisan du « développement Lean », je ne peux que décourager une telle approche. Un produit qui passe du stade de développement actif à celui de maintenance est un produit qui se dégrade, c’est une histoire sans fin. Confier le travail à une équipe de maintenance mutualisée se révèlerait inefficace pour maintenir le système opérationnel. L’espace dévolu à cet article n’est hélas pas suffisant pour approfondir ce point de façon plus détaillée.
Coûts de maintenance
Lorsque les produits en arrivent à ce stade, l’équipe qui a fait le travail à l’origine n’est généralement plus disponible. La valeur offerte aux utilisateurs cesse alors d’être optimisée. Si le système adopte ce statut et même si de petits investissements (comme l’ajout d’une nouvelle série de fonctionnalités) sont réalisés, rien ne justifie un retour aux étapes antérieures du cycle de vie de l’application. Les coûts continuent donc de s’ajouter dans le cadre de la maintenance.
À ce stade, les produits évoluent rarement dans les Maturity Models. L’équipe de maintenance responsable maintiendra donc le statut ou laissera le système se dégrader. Quels que soient les efforts pour conforter le produit sur ces Maturity Models, les coûts continuent de s’accumuler du côté de la maintenance. Le concept de Maturity Models est la méthode utilisée par défaut par Pentalog pour donner à ses clients de la visibilité sur leur position sur différents axes informatiques.
Coûts opérationnels
Les licences pour les bibliothèques intégrées au produit s’ajoutent ici aussi. Les sauvegardes et les abonnements aux plateformes entrent également dans les coûts opérationnels.
L’utilisation de services tiers requérant leurs propres souscriptions est un autre exemple intéressant. Nous avons par exemple vu le cas d’un scénario B2B pour une jeune entreprise, où le produit retenait suffisamment d’utilisateurs et où il n’y avait aucune place pour développer le reporting. Une solution temporaire a alors été fournie avec un accès sécurisé à du stockage esclave pour de la self-service BI. Ces outils requérant généralement un paiement par utilisateur, les licences dédiées ont donc été comptabilisées dans les coûts opérationnels.
Former les utilisateurs ou surveiller le système fait aussi partie des coûts opérationnels.
Coûts de support
Le support client ou utilisateur, quel que soit le niveau d’assistance, ainsi que l’infrastructure et les outils nécessaires au soutien des processus de support font eux aussi partie des coûts de support.
Beaucoup de produits ne disposent pas de programmes de support sophistiqués. Cette rubrique peut alors rester vierge et le support ponctuel nécessaire peut être ajouté à d’autres colonnes. Le plus important est de ne pas perdre de vue ces coûts.
La mise hors service est un aspect souvent oublié dans les estimations initiales. Pourtant, effectuée correctement, elle peut être compliquée et onéreuse. Et selon l’organisation, la mise hors service peut impliquer non pas une étape unique, mais une série d’étapes dans un processus long et coûteux. Nettoyer et anonymiser les données, fermer les serveurs et adapter le processus opérationnel sont également des activités à intégrer ici.
La migration des utilisateurs vers un nouveau système fait généralement partie des coûts d’évolution de la nouvelle initiative, même s’il serait plus sain d’en évaluer approximativement le budget dès le début.
La seconde partie de cet article s’intéresse à la préparation au coût total de possession, aux différentes approches du TCO adoptées par les CTO ainsi qu’aux avantages majeurs de la réflexion sur le TCO.
***
Si vous voulez perfectionner vos compétences de CTO ou souhaitez évaluer l’adéquation d’un candidat au poste de CTO, découvrez-en plus sur l’évaluation de CTO pour le Growth et l’évaluation de CTO pour le recrutement que vous propose Pentalog.
À l’origine, cet article a été publié sur le blog CTO Craft, le partenaire de Pentalog pour la formation des CTO.
