Vous êtes déjà chez Microsoft : faut-il adopter une seconde plateforme

La réponse n’est pas « non ». Elle est : regardez d’abord ce que vous achetez réellement, parce que ce n’est pas un logiciel. C’est un second socle.

Ce qu’est une suite intégrée, dans ses propres termes

Odoo se décrit comme « une suite d’applications professionnelles open source », dont la proposition de valeur est d’être « à la fois très facile à utiliser et entièrement intégrée ». Une cinquantaine d’applications principales, complétées par des milliers de contributions, que l’on ajoute une par une à mesure que les besoins évoluent.

C’est une description exacte, et c’est aussi tout le sujet. Une suite entièrement intégrée est une plateforme. Elle apporte sa propre gestion des utilisateurs, ses propres droits, sa propre base de données, sa propre logique de mise à jour, ses propres sauvegardes, ses propres compétences.

Si vous tournez déjà sur Microsoft 365, vous en avez déjà une. La décision n’est donc pas « quel outil est le meilleur », c’est « combien de socles mon entreprise peut-elle entretenir ».

Ce que coûte le second socle, et qui n’est jamais dans le devis

Le prix des licences est en général le poste le plus faible, et c’est ce qui rend la comparaison trompeuse. Ce qui coûte, c’est le doublon :

• Deux annuaires. Une arrivée, un départ, un changement de fonction doivent être répercutés à deux endroits. Ce qui n’est pas fait aux deux endroits devient un compte orphelin — le défaut de sécurité le plus banal et le plus fréquent.
• Deux modèles de droits. Qui voit quoi se décide deux fois, selon deux logiques différentes, et se contrôle deux fois lors d’un audit.
• Deux plans de sauvegarde et de reprise. Deux fois la question « en cas de sinistre, on repart d’où », et deux fois la nécessité de l’avoir testée.
• Deux jeux de compétences. Celles qui font vivre votre socle actuel ne servent pas sur l’autre. En Suisse romande, le vivier n’est pas le même, et le coût non plus.
• Deux surfaces à surveiller. Chaque plateforme exposée est une porte, et chacune demande son suivi de correctifs.

Aucun de ces postes n’apparaît dans une démonstration. Tous apparaissent la deuxième année.

Remarque : ce raisonnement vaut dans les deux sens. Une entreprise dont le cœur d’activité tourne déjà sur une suite intégrée aurait le même tort d’y ajouter un second socle pour un besoin ponctuel. Le principe n’est pas « Microsoft », c’est « un socle, et on construit dessus ».

Le mécanisme qui alourdit les développements, quel que soit l’éditeur

C’est le point le plus mal compris, et il ne vise personne en particulier.

Quand on personnalise un produit intégré, on modifie un cœur partagé par tous ses modules. Chaque adaptation crée une dépendance entre votre travail et une version précise du produit. À la mise à jour suivante, il faut vérifier que chaque adaptation tient toujours — et le coût de cette vérification croît avec le nombre d’adaptations. Plus on développe, plus chaque montée de version coûte cher. C’est arithmétique.

Ce n’est pas un défaut d’un éditeur : c’est la nature d’un produit intégré. Nous venons d’en donner un exemple sur le terrain de Microsoft lui-même, avec un logiciel de gestion de la relation client hors support dont la couche de personnalisation représente l’essentiel de l’effort de sortie. Le mécanisme est identique.

La conséquence pratique : si votre besoin est de développer beaucoup, un produit intégré est le mauvais endroit où le faire. Un outil bâti à côté du socle, relié par des échanges propres, n’hérite pas de cette dette.

Les cas où la seconde plateforme se justifie

Ils existent, et il faut les nommer honnêtement :

• votre métier a un besoin standard et complet couvert par la suite, et vous acceptez de vous plier à sa façon de faire sans la personnaliser ;
• vous n’avez pas encore de socle établi, et le choix est ouvert ;
• une contrainte de coût de licence est réellement déterminante à votre échelle, et vous avez chiffré le doublon d’exploitation en face.

Le fil commun : la seconde plateforme se justifie quand on l’adopte telle quelle. Elle se justifie mal quand on l’adopte pour la transformer.

Les cinq questions à poser en réunion

1. Cette suite remplacera-t-elle un outil existant, ou s’ajoutera-t-elle à l’existant ?
2. Qui gérera les comptes, et comment un départ sera-t-il répercuté aux deux endroits ?
3. Combien d’adaptations sont prévues dès la première année ?
4. Qui fait la montée de version, à quelle fréquence, et qui vérifie les adaptations ?
5. Ce que nous voulons construire existe-t-il déjà dans ce que nous payons ?

La cinquième surprend souvent. Une partie des besoins présentés comme justifiant une nouvelle plateforme — un formulaire de demande, un circuit de validation, un suivi partagé, un tableau de bord — se traite dans l’environnement déjà en place, dont le modèle de licence a d’ailleurs changé de logique : ce n’est plus le nombre d’applications qui coûte, c’est le nombre de personnes.

Notre lecture

Nous ne vendons pas de progiciel de gestion intégré, et cet article ne défend pas un produit contre un autre. Il défend une règle d’architecture : un socle, et on construit dessus. Quand ce socle existe déjà, qu’il est payé, administré et maîtrisé, la charge de la preuve appartient à celui qui propose d’en installer un second.

Lambert Consulting construit des outils sur le socle que vous avez, et relie ceux qui existent déjà — y compris ceux qui ne sont pas de Microsoft. Quand la bonne réponse est de ne rien construire et de simplement faire circuler l’information entre vos outils actuels, c’est celle-là que nous proposons.

Les sources

• Tarifs Power Apps
• Environnements Power Platform
• Odoo — présentation de l’entreprise