Coût total de possession des logiciels de gouvernance : évaluer l'effort de mise à jour et la sécurité des mises à jour

Lors du choix d'un logiciel de gouvernance, le prix de la licence, la mise en œuvre et l'exploitation constituent les éléments fondamentaux de la comparaison économique. Pour une évaluation sur plusieurs années, il convient également de prendre en compte les coûts liés aux changements techniques, organisationnels et réglementaires. À cet égard, il est déterminant de savoir dans quelle mesure la plateforme est configurable et si les adaptations spécifiques au client sont conservées lors des mises à jour du produit.

L'ajout de nouveaux champs obligatoires, de rôles, d'autorisations ou de rapports fait partie intégrante du développement d'une organisation de gouvernance. Si ces exigences doivent être régulièrement programmées par l'éditeur, cela engendre non seulement des coûts de développement externes, mais aussi des charges internes liées à la coordination, à la passation de commandes, aux tests et à la mise en place. Un prix de licence bas peut donc s’accompagner de coûts d’exploitation globaux plus élevés.

Tenir compte des modifications intervenant au cours de la durée d'utilisation

Les offres logicielles indiquent dans un premier temps les coûts immédiatement identifiables : licence annuelle, mise en œuvre, hébergement, assistance technique ainsi que, le cas échéant, formation et migration. Ces postes se comparent relativement facilement, mais ne reflètent qu’une partie des implications économiques d’un choix de plateforme s’étalant sur plusieurs années.

Au cours de la durée d'utilisation, l'organisation et ses besoins évoluent. De nouvelles sociétés sont intégrées, les responsabilités sont redéfinies et de nouvelles langues deviennent nécessaires. Parallèlement, les exigences réglementaires, les audits internes ou les demandes de la direction peuvent nécessiter des modifications des modèles de données, des processus et des analyses.

Sur le site Protection des données Cela concerne par exemple la structure du répertoire des activités de traitement, une logique de risque adaptée ou des processus de révision à l'échelle du groupe comportant des variantes locales. À cela peuvent s’ajouter des autorisations supplémentaires lors de l’implication de prestataires de services, de nouveaux indicateurs clés, des processus de gouvernance de l’IA, des exigences issues de la gestion de la sécurité de l’information ou des justificatifs complémentaires pour les audits internes.

Dans le cadre de l'évaluation économique, ces ajustements doivent être considérés comme faisant partie intégrante de l'exploitation courante. Les entreprises devraient donc vérifier, avant même de faire leur choix, quelles modifications peuvent être effectuées par leurs propres administrateurs et lesquelles nécessitent une intervention du fournisseur au niveau du développement.

Quels coûts doivent être pris en compte dans une analyse du coût total de possession (TCO) ?

Le coût total de possession (TCO) désigne l'ensemble des coûts sur toute la durée d'utilisation. Dans le cas des logiciels de gouvernance, cette analyse englobe la mise en place, l'exploitation courante et le développement ultérieur. Pour permettre une comparaison structurée, on peut distinguer cinq catégories de coûts :

Cette classification permet de comparer la structure des coûts des différentes offres. Un prestataire peut sembler plus avantageux lors de la signature du contrat, mais des coûts supplémentaires considérables liés aux modifications peuvent s'ajouter au fil des années. À l'inverse, une licence plus onéreuse peut s'avérer économiquement justifiable si les coûts d'exploitation et d'adaptation sont en conséquence moins élevés.

Il convient à cet égard de prendre en compte à la fois les prestations externes du prestataire et les coûts internes de l'entreprise. Une évaluation qui se limite exclusivement aux prix indiqués dans l'offre ne tient pas compte d'une partie importante des coûts ultérieurs.

Charges externes et internes liées aux demandes de modification

Une exigence technique initialement limitée peut entraîner plusieurs modifications interdépendantes. Si, par exemple, un nouveau champ s'avère nécessaire, il peut être nécessaire de déterminer en même temps pour quelles sociétés il est obligatoire. Une réponse spécifique doit déclencher un contrôle ; en cas de risque élevé, le délégué à la protection des données doit être impliqué et la direction a besoin d’une analyse filtrable par pays et par unité opérationnelle. Pour une société française, une version linguistique supplémentaire peut s’avérer nécessaire.

Dans la mesure où ces exigences ne peuvent être satisfaites que par un développement sur mesure, la concertation technique est généralement suivie des étapes suivantes : cahier des charges, offre, passation de commande, développement, tests, planification de la mise en production, déploiement et Documentation. Ces étapes demandent un certain effort, même si la modification technique en elle-même semble relativement simple.

Au sein de l'entreprise, plusieurs services peuvent être concernés. Les services spécialisés décrivent les besoins, la protection des données ou Conformité précisent les exigences, le service informatique en évalue les implications, le service des achats passe commande et la gestion de projet coordonne la mise en œuvre. Les utilisateurs doivent ensuite tester et Documentation être adapté.

Les prestations de développement doivent être prises en compte comme un élément de coût régulier. Toutefois, pour évaluer la rentabilité, il convient de tenir compte de la fréquence à laquelle elles sont nécessaires pour le développement technique continu. Si chaque modification est mise en œuvre de cette manière, même des coûts unitaires modérés peuvent finir par représenter une somme considérable sur la durée de vie de l'application.

La configurabilité en tant que critère d'évaluation économique

Le « no-code » peut permettre d'apporter des modifications fonctionnelles sans recourir à une programmation personnalisée. Dans le cas des systèmes de gouvernance, cela concerne notamment l'adaptation des champs de données, des rôles, des formulaires, des questionnaires, des workflows et des analyses. L'intérêt économique dépend des éléments qui sont effectivement configurables et de l'effort que cela implique.

Si un administrateur disposant des compétences requises est en mesure de répondre à une demande en quelques heures, la structure des coûts et des délais est différente de celle d'un projet de développement s'étalant sur plusieurs semaines. Cela peut permettre de réduire les coûts de développement externes, les délais d'attente et les efforts internes consacrés au projet. Parallèlement, l'organisation peut gagner en autonomie vis-à-vis du fabricant dans le cadre du développement de ses processus.

La simple mention indiquant qu’un logiciel est „ personnalisable “ ne suffit donc pas pour l’évaluation. Elle peut désigner aussi bien un développement payant réalisé par l’éditeur qu’une configuration pouvant être effectuée de manière autonome. Au cours de la procédure de sélection, il convient de déterminer qui peut modifier quels éléments, quelles connaissances sont nécessaires pour cela et quel sera l'impact de ces modifications sur les futures mises à jour.

Pour une plateforme de gouvernance d'entreprise, il convient notamment d'examiner les options de configuration suivantes :

• Champs et logique des champs obligatoires : Ajout d'informations et mentions obligatoires sous certaines conditions, en fonction du risque, du rôle, de la société, de l'état d'avancement du processus ou d'autres éléments.
• Rôles et autorisations : Adaptation des responsabilités et des droits d'accès à chaque organisation.
• Workflows et validations : Modification des processus de contrôle, de révision et de validation, y compris l'ajout d'étapes d'autorisation supplémentaires.
• Délais et procédures d'escalade : Configuration des rappels, des délais et des procédures d'escalade.
• Formulaires et questionnaires : Évolution des requêtes techniques sans version distincte du produit.
• Rapports : Adaptation des analyses et des dimensions d'analyse supplémentaires.
• Organisation et multilinguisme : Intégration d'autres sociétés, sites, équipes et divisions, ainsi que de nouvelles versions linguistiques.
• Adaptations réglementaires : Modification des processus de gouvernance concernés lorsque de nouvelles exigences doivent être prises en compte.

Ces possibilités doivent être évaluées au cas par cas, en fonction des besoins concrets de l'entreprise. Pour déterminer la rentabilité, il est essentiel de savoir dans quelle mesure elles permettent de couvrir les changements prévisibles dans le cadre de l'exploitation courante.

Sécurité des mises à jour et conservation des configurations spécifiques aux clients

La configurabilité n'est économiquement viable que dans une mesure limitée si les adaptations spécifiques au client doivent être recréées ou entièrement remaniées après une mise à jour du produit. Outre les possibilités de modification, il convient donc d'examiner comment ces adaptations se comportent lors des versions ultérieures.

Une distinction claire entre la norme du produit et la configuration spécifique au client doit permettre de poursuivre le développement de la norme tout en conservant les configurations existantes. Il doit être possible d'utiliser les nouvelles fonctionnalités du produit sans avoir à recréer à chaque fois les processus déjà mis en place.

En l'absence de cette séparation, des efforts supplémentaires peuvent s'avérer nécessaires. Après une mise à jour, il faut alors déterminer quelles adaptations continuent de fonctionner, lesquelles ont été écrasées et lesquelles doivent être développées à nouveau. Dans le pire des cas, les modifications spécifiques au client peuvent compliquer, voire empêcher, une mise à niveau. L’individualisation peut ainsi entraîner des dépendances techniques et des coûts récurrents.

Les entreprises devraient donc demander précisément quelles configurations seront conservées, quels tests de régression sont nécessaires et si certaines adaptations pourraient bloquer les futures versions. Dans ce contexte, la sécurité des mises à jour est un critère essentiel pour préserver les investissements déjà réalisés.

Exemple simplifié de coûts sur cinq ans

L'importance des ajustements ultérieurs peut être illustrée à l'aide d'un exemple de calcul simplifié. Les montants suivants sont donnés à titre d'exemple :

Sur cette base, l'avantage financier du fournisseur A s'élève dans un premier temps à 170 000 euros. Pour la suite de l'analyse, on suppose que le fournisseur A devra supporter les coûts externes liés aux changements suivants au cours de chacune des quatre années d'exploitation suivant l'année de mise en service :

• Quatre demandes de modification mineures de 8 000 euros chacune : soit un total de 32 000 euros.
• Une adaptation majeure du flux de travail : 25 000 euros.
• Adaptations des rapports : 10 000 euros.

Les coûts externes liés aux modifications s'élèvent ainsi à 67 000 euros par an et à 268 000 euros sur quatre ans. Si l'on ajoute à cela la licence et la mise en œuvre, le montant total pour le fournisseur A s'élève à 698 000 euros. Les coûts internes, tels que ceux liés aux tests de version supplémentaires et à la coordination, ne sont pas encore pris en compte dans ce montant.

Chez le fournisseur B, il faut compter dans un premier temps 600 000 euros pour la licence et la mise en œuvre. Il faut également prendre en compte les coûts liés aux configurations nécessaires et les efforts internes. Si ces mêmes modifications peuvent être configurées avec un effort suffisamment faible, l'avantage financier initial du fournisseur A peut s'inverser.

Cet exemple ne constitue pas un calcul complet du coût total de possession (TCO), mais il illustre pourquoi une comparaison fiable nécessite également des hypothèses concernant la fréquence et l'ampleur des modifications ultérieures. La configurabilité en soi ne permet pas encore de déduire une économie de coûts précise.

Exigences relatives à l'évaluation économique dans l'appel d'offres

Dans le cadre d'un choix de plateforme s'étalant sur plusieurs années, il n'est possible d'anticiper les besoins futurs que de manière limitée. L'appel d'offres (RFP) doit donc non seulement décrire les processus existants, mais également aborder leur évolution future. Les réponses doivent indiquer clairement quelles prestations sont incluses dans l'offre standard et dans quels cas des coûts supplémentaires sont à prévoir.

Les questions suivantes, notamment, doivent être prises en compte dans le cadre de l'évaluation :

Configuration

Quels champs les administrateurs peuvent-ils compléter eux-mêmes ? Est-il possible de modifier les champs obligatoires, les logiques conditionnelles, les workflows, les étapes de validation, les rappels et les escalades sans avoir à programmer ?

Rôles et droits

Est-il possible de créer ses propres rôles et d'adapter les autorisations en fonction d'un objet, d'un statut ou d'une organisation ?

Rapports

Quels rapports et tableaux de bord le client peut-il configurer lui-même ? Pour quelles modifications l'intervention du fabricant est-elle nécessaire ?

Organisation

Comment les nouvelles sociétés, équipes, sites et unités opérationnelles sont-ils ajoutés ? Quels sont les coûts de mise en œuvre supplémentaires que cela entraîne ?

Mises à jour

Quelles configurations spécifiques au client sont conservées lors des mises à jour du produit ? Quels tests de régression sont nécessaires ? Les personnalisations peuvent-elles bloquer une future version ?

Demandes de modification

Quelles modifications sont incluses dans la configuration standard et lesquelles font l'objet d'une facturation séparée ? Comment s'effectue la facturation et quels sont les délais moyens à prévoir ?

Administration

Quelles configurations le client peut-il effectuer lui-même ? Quelles sont les compétences requises pour les administrateurs et dans quels cas des connaissances en développement sont-elles nécessaires ?

Ces questions doivent être prises en compte dans l'évaluation économique avant la conclusion du contrat. Elles concernent les coûts récurrents, la durée des adaptations ultérieures et la dépendance vis-à-vis du prestataire.

Feuille de route du produit et évolution de la norme

La stratégie produit peut également influencer le coût total de possession. Si les exigences fonctionnelles sont développées dans le produit standard, cela peut réduire le besoin de projets spécifiques au client. En revanche, si les extensions sont principalement mises en œuvre de manière personnalisée, c’est le client concerné qui supporte en grande partie les coûts de développement associés.

La procédure de sélection doit donc permettre de déterminer quelles fonctionnalités doivent être intégrées dans la version standard, à quelle fréquence les mises à jour sont publiées et comment les modifications réglementaires sont prises en compte. Il est également important de savoir quelles extensions profitent à l'ensemble des clients et comment le fournisseur fait la distinction entre le développement général du produit et les prestations spécifiques à chaque client.

La feuille de route doit donc être considérée comme un élément de l'analyse des coûts, car elle donne une indication de la mesure dans laquelle le développement ultérieur du produit peut rendre superflues des adaptations individuelles ultérieures.

Gestion contrôlée et contraintes de temps

La possibilité de configurer soi-même le système implique une définition claire des responsabilités. Tous les utilisateurs ne devraient pas pouvoir modifier les workflows, les champs obligatoires ou les autorisations, car une configuration erronée peut nuire aux processus de vérification et de validation prévus.

Les entreprises doivent donc définir qui est autorisé à effectuer des modifications et qui est chargé de les vérifier. Lors de l'évaluation de la plateforme, il convient également de déterminer si les modifications de configuration font l'objet d'un contrôle de version, quelles sont les possibilités de test disponibles et s'il est possible de restaurer une configuration antérieure. Le « no-code » modifie la manière de mettre en œuvre les projets ; la nécessité d’une administration contrôlée demeure.

Par ailleurs, le délai de mise en œuvre doit être pris en compte en tant que facteur économique. Si une modification de processus imposée par la réglementation doit être mise en œuvre à court terme, le lancement préalable d'un projet de développement peut entraîner des retards. Des dépendances similaires peuvent survenir en cas de changements organisationnels internes ou d'exigences supplémentaires issues d'audits.

Les conséquences économiques d'un retard peuvent aller au-delà du coût de la demande de modification. La capacité d'adaptation doit donc également être évaluée en fonction de la possibilité d'effectuer les ajustements nécessaires dans les délais applicables.

Exigences relatives à une plateforme telle qu'Ailance

Les critères décrits doivent également être appliqués à une plateforme telle qu’Ailance. Les processus de gouvernance se composent d’objets, de champs, de rôles, de workflows, de décisions, de tâches, de revues, de rapports et des relations entre ces éléments. Dans la mesure où ces composants peuvent être configurés de manière contrôlée, cela permet de limiter le recours à des projets de développement spécifiques pour les modifications métier.

L'objectif est de disposer d'un produit standard offrant des possibilités de configuration qui soient conservées lors des mises à jour ultérieures. Les nouvelles exigences doivent pouvoir être mises en œuvre sur la plateforme existante sans entraver la poursuite du développement du produit. Dans le cadre de déploiements d'entreprise à long terme, il convient d'accorder une attention particulière à cet équilibre entre le produit standard, la personnalisation et la sécurité des mises à jour.

Épreuve pratique dans le cadre du concours de recrutement

L'évaluation doit concilier les points de vue du service métier, du service des achats, du service informatique et de la direction. Tandis que le service métier évalue la représentation de ses processus, le service des achats se penche sur les prix et le service informatique examine le fonctionnement ainsi que l'intégration. Pour les responsables financiers, ce sont les coûts globaux sur plusieurs années qui sont déterminants ; du point de vue de la direction informatique, il convient en outre d'évaluer la dépendance future vis-à-vis du fournisseur.

Pour concrétiser cela, on peut se référer à cinq exigences issues de l'exploitation courante :

1. Un nouveau champ obligatoire est ajouté.
2. Une réponse précise déclenche un contrôle supplémentaire.
3. Une autre personne habilitée à valider est intégrée à un workflow.
4. La direction a besoin d'un nouveau rapport.
5. Une filiale a besoin d'une variante locale d'un processus.

Pour chaque exigence, il convient de déterminer si l'entreprise est en mesure de la mettre en œuvre elle-même, combien de temps prendra la modification, quels en seront les coûts et si un projet de fabrication est nécessaire. Il faut également vérifier comment la configuration modifiée se comportera lors de la prochaine mise à jour du produit.

Cette analyse permet de mieux cerner les conséquences économiques des possibilités d'adaptation proposées et complète la comparaison des fonctionnalités existantes en tenant compte des coûts liés à leur développement ultérieur.

Cadre de référence pour la décision d'achat

Un prix d'entrée de gamme bas peut s'accompagner de coûts d'exploitation globaux avantageux si la plateforme est suffisamment configurable et si son fonctionnement ne nécessite que peu d'efforts. De même, une licence plus onéreuse peut se justifier d'un point de vue économique par des coûts de modification moins élevés. Un prix plus élevé ne garantit pas en soi une meilleure rentabilité.

La décision d'achat dépend donc de la structure des coûts sur la durée de vie utile, des changements prévisibles et des interdépendances qui en découlent. La configurabilité, la fiabilité des mises à jour et la feuille de route du produit doivent être prises en compte dans cette évaluation, car elles influent sur l'effort que l'entreprise devra fournir ultérieurement pour faire évoluer ses processus de gouvernance.

Questions et réponses

Comment évaluer le coût total de possession d'un logiciel de gouvernance ?

Il convient de prendre en compte la licence, la mise en place et l'exploitation, ainsi que les coûts liés aux modifications, aux mises à jour et aux extensions organisationnelles. Les prestations externes et les charges internes doivent être prises en compte sur la même période d'analyse.

Pourquoi le prix de la licence ne suffit-il pas pour comparer des logiciels ?

Après la mise en place, des coûts supplémentaires peuvent survenir pour des adaptations techniques, des tests et des tâches administratives. Des modifications fréquentes peuvent modifier considérablement la comparaison de prix initiale sur plusieurs années.

Quels coûts induits peuvent être générés par les logiciels de gouvernance ?

Cela comprend les demandes de modification, les développements spécifiques aux clients, les tests de régression après les mises à jour, les rapports supplémentaires, les adaptations des workflows, les nouveaux rôles, les versions dans d'autres langues et les adaptations liées à la réglementation.

Dans quelles conditions le « no-code » peut-il réduire le coût total de possession (TCO) ?

Si les modifications nécessaires peuvent être configurées sans recourir au développement logiciel sur mesure, cela permet de limiter les coûts de développement externes et les efforts consacrés aux projets en interne. Il convient toutefois de tenir compte de l'effort de configuration réel.

Pourquoi la sécurité des mises à jour revêt-elle une importance économique ?

Si les configurations spécifiques aux clients sont conservées lors des mises à jour des produits, il n'est pas nécessaire de recréer les processus déjà mis en place à chaque nouvelle version. Il convient également de vérifier quels tests et adaptations restent nécessaires.

Quels changements devraient pouvoir être mis en œuvre sans projet de développement ?

Sont notamment pris en compte les champs, les logiques des champs obligatoires, les rôles, les workflows, les validations, les rappels, les escalades et les questionnaires, ainsi que le plus grand nombre possible de personnalisations des rapports. L'étendue requise dépend des processus de l'entreprise.

Quelles questions relatives aux demandes de modification doivent figurer dans un appel d'offres ?

Il convient de préciser la différence par rapport à la configuration standard, les prestations à fournir par le fabricant, les modalités de facturation et les délais de mise en œuvre habituels.

Quelle est l'importance de la feuille de route des produits pour le coût total de possession (TCO) ?

Le développement de la norme pourrait rendre superflus les projets spécifiques aux clients. Ce qui importe, c'est de déterminer quelles fonctionnalités et quelles exigences réglementaires doivent être intégrées dans le produit standard.

Une plateforme de gouvernance plus coûteuse est-elle automatiquement plus rentable ?

Non. C'est la structure globale des coûts sur toute la durée de vie qui est déterminante. Une plateforme moins chère peut s'avérer plus avantageuse sur le plan économique si elle offre une flexibilité de configuration suffisante et des coûts d'exploitation faibles.

Quelle est la question centrale lors de l'évaluation des modifications ultérieures ?

Il convient de déterminer les efforts externes et internes qu'implique la modification d'un processus modélisé, et de vérifier si cette adaptation sera conservée lors des futures mises à jour.