Introduire un SaaS : plan de projet, jalons et responsabilités

Introduire un SaaS ne signifie pas développer un logiciel

SaaS signifie Software as a Service : l'application s'exécute dans le cloud et est mise à disposition via Internet ; l'accès se fait par le biais d'un navigateur ou d'une application. Aucune installation sur un ordinateur ou un serveur propre n'est nécessaire. Le paiement s'effectue généralement par abonnement, mensuel ou annuel. Les mises à jour, les correctifs de sécurité et les sauvegardes relèvent du fournisseur. Exemples connus : Microsoft 365, Google Workspace, Slack, Salesforce ou Zoom.

Pour le projet, cela change fondamentalement la tâche : il ne s'agit pas d'un projet de développement avec une feuille de route produit propre, mais d'un projet d'introduction et d'intégration comprenant la configuration, le concept d'autorisations, la reprise des données, les interfaces, la formation et la réception. Du côté de l'entreprise utilisatrice, la responsabilité des données – intégrité, conservation et sauvegarde – ainsi que la gestion des accès, les droits des utilisateurs et la restauration après un incident demeurent internes.

La large diffusion ne rend pas l'introduction plus simple pour autant : selon Statista, 70 % des entreprises comptant jusqu'à 500 collaborateurs et 56 % de toutes les entreprises dans le monde utilisent des applications SaaS. Un plan réaliste est donc de mise, avec des décisions, des rôles, des fenêtres de test et des critères de réception – et non l'hypothèse qu'un produit standard couvre tous les cas particuliers.

Autre différence par rapport à une installation propre : les nouvelles versions et les fonctionnalités sont déployées automatiquement par le fournisseur, de sorte que les utilisateurs travaillent toujours avec la version la plus récente. Dans le plan de projet, la planification interne des versions devient superflue ; il reste toutefois nécessaire de définir des fenêtres temporelles pour les tests après les mises à jour majeures du fournisseur et d'assurer une communication claire auprès des utilisateurs.

Clarifier l'objectif, les processus et les exigences

Avant de choisir le produit, il faut analyser la situation de départ : l'architecture système existante, les processus métier et les exigences organisationnelles sont évalués de manière globale. Il en résulte une stratégie cloud qui prend en compte les aspects technologiques, économiques et liés à la sécurité, qui est ancrée dans la stratégie de l'entreprise et qui ne repose pas uniquement sur l'IT. Elle fournit une feuille de route pour la modernisation de l'IT, des décisions d'investissement transparentes et une architecture qui évolue avec l'entreprise.

Éléments à relever : cartographie des processus avec les flux concernés, données et flux de données associés, interfaces existantes, rôles et niveaux d'autorisation, exigences concernant le lieu de stockage des données et langues nécessaires. Il en découle un objectif avec des critères vérifiables : processus à couvrir, nombre d'utilisateurs, volume de données, cadre budgétaire et délais.

L'objectif est plus qu'une simple étude préalable : il sert ultérieurement de référence pour le choix du fournisseur et de critère de réception après le déploiement. La complexité réduite et les dépendances technologiques minimisées peuvent se mesurer au nombre de systèmes remplacés et aux interfaces restantes.

Choix de la solution : critères axés sur la Suisse

Un catalogue de critères permet d'éviter que les impressions tirées des démonstrations ne dictent le choix. Il convient de vérifier l'étendue des fonctionnalités par rapport aux exigences des processus relevés, le stockage des données en Suisse ou dans l'UE (exigence pour la conformité à la LPD), le multilinguisme DE/EN/FR en standard pour le marché suisse, la facturation et les modes de paiement, ainsi que le soutien du fournisseur lors de l'introduction. De nombreux clients B2B suisses privilégient le paiement par virement IBAN ; vérifiez si le fournisseur le prend en charge et si les factures sont émises en CHF avec la TVA suisse – en Suisse, l'assujettissement à la TVA s'applique dès un chiffre d'affaires annuel de CHF 100'000.

Les critères techniques sont tout aussi importants. Dans une architecture multi-tenant, plusieurs clients utilisent la même instance logicielle, mais leurs données sont entièrement séparées. Les fonctions typiques d'une solution SaaS sont la gestion des utilisateurs et des droits, la séparation sécurisée des données, les accès API, la gestion des abonnements et les analyses. La scalabilité compte également : des licences supplémentaires peuvent généralement être commandées en quelques clics, ce qui réduit la charge de travail en cas de croissance ou de changement de personnel.

Pour une comparaison structurée, une matrice d'évaluation pondérée est appropriée : les mêmes questions à tous les fournisseurs, une évaluation par critère, et ce n'est qu'ensuite que l'on fait la somme. Un accès de test avec ses propres données d'exemple montre si les processus clés sont effectivement couverts. Il faut clarifier par écrit les délais de support et de réaction, la communication sur les versions, l'exportation des données en cas de départ, les délais de résiliation et les règles de prix en cas d'augmentation du nombre d'utilisateurs. Un classement ne remplace pas cet examen – il ne fait que résumer ce qui a été évalué au préalable avec ses propres critères.

Critères pour le choix du fournisseur SaaS (référence Suisse)

Le plan de projet : phases de la conception au déploiement

Un déroulement éprouvé s'articule en cinq phases : concept et périmètre, décisions d'architecture et d'intégration, pilote avec un groupe d'utilisateurs limité, déploiement à grande échelle et mise à l'échelle ultérieure. Le développement SaaS connaît une approche comparable : stratégie produit, conception de l'architecture, validation du MVP avec de vrais utilisateurs, mise à l'échelle. Chaque phase se termine par des résultats définis qui doivent être présents avant que la suivante ne débute.

Phase 1 – Concept et périmètre : les résultats sont l'analyse des processus, la liste des exigences, l'avant-projet, l'estimation des quantités (utilisateurs, données, interfaces) et l'estimation des coûts. Il faut décider quels modules et domaines fonctionnels seront introduits et dans quel ordre, et quels groupes d'utilisateurs seront les premiers. Sans cette décision, ni l'appel d'offres ni la comparaison des offres ne sont possibles.

Phase 2 – Architecture et intégration : c'est ici que se prennent les décisions techniques fondamentales – exploitation multi-tenant ou single-tenant, concept d'isolation des données, conception de l'API, lieu de stockage des données, modèle d'autorisations et liste des interfaces vers les systèmes existants. Résultats : concept technique, spécification des interfaces, plan de migration et concept de test.

Phase 3 – Pilote : un groupe d'utilisateurs limité travaille avec les fonctions clés et des données réelles ; les erreurs, les lacunes et les problèmes d'utilisation sont relevés et priorisés. Résultats : cas de test réussis, liste des erreurs corrigées, documents de formation, données de test migrées. Ce n'est que lorsque les processus clés fonctionnent en phase pilote que le déploiement est judicieux.

Phase 4 – Déploiement : la reprise des données, la formation, le support et la communication se déroulent selon un calendrier établi pour chaque groupe d'utilisateurs. Résultats : démarrage en production avec un nombre d'utilisateurs défini, formations achevées, parcours de support fonctionnel. Phase 5 – Mise à l'échelle : extension à d'autres domaines, modules supplémentaires, automatisation et optimisation des performances. L'introduction ne s'arrête pas à la première version en ligne ; le développement du produit continue chez le fournisseur, et l'entreprise planifie en conséquence l'exploitation et l'extension.

Phases du projet d'introduction d'un SaaS

Définir des jalons et les rendre mesurables

Un jalon ne sert d'instrument de pilotage que s'il contient quatre éléments : un résultat vérifiable, un critère indiquant quand il doit être atteint, et un rôle responsable. Exemples : analyse des processus achevée, choix du fournisseur approuvé par le maître d'ouvrage, phase de test réussie avec de vrais utilisateurs, démarrage en production, objectifs d'utilisation atteints après une période d'observation définie.

Pour que les jalons servent de critères d'arrêt, chaque critère doit être formulé de manière à pouvoir échouer. Le pilote est considéré comme réussi si les processus clés convenus sont exécutés avec des données réelles et si la restauration des données est prouvée – et non si « l'ambiance est bonne ». Si un critère n'est pas atteint, les conséquences doivent être définies à l'avance : renégociation, formation complémentaire, nouveau cycle de test ou abandon du projet.

La dimension temporelle dépend fortement de l'ampleur du projet. Celui qui n'introduit qu'un domaine central a besoin de moins d'étapes de migration, d'interfaces et de formations que pour une étendue fonctionnelle complète avec plusieurs modules. Les dates fixes doivent donc être liées à des événements – approbation du budget, expiration d'un ancien contrat, fin d'une phase pilote – et non à des souhaits calendaires qui réduiraient l'effort de test.

Qui assume quoi : responsabilité partagée plutôt que tout chez le fournisseur

La base est le modèle de responsabilité partagée : la sécurité de l'infrastructure incombe au fournisseur SaaS, la sécurité des données incombant pour l'essentiel à l'entreprise utilisatrice. De nombreuses entreprises supposent à tort que le fournisseur protège également leurs données. En réalité, l'intégrité, la conservation et la sauvegarde des données restent chez le client – tout comme la gestion des accès, les droits des utilisateurs et la restauration des données.

Du côté du fournisseur, on trouve la mise à disposition depuis des centres de données sécurisés, l'exploitation, les mises à jour, la maintenance, les correctifs de sécurité et les sauvegardes de l'infrastructure. Du côté de l'entreprise, on trouve la responsabilité des données, le concept d'autorisations, la sauvegarde propre des données SaaS, le plan d'urgence et la conformité.

Des rôles concrets dans le projet peuvent en être déduits : le maître d'ouvrage décide du budget et de l'approbation des jalons. Les départements spécialisés fournissent les processus, les cas de test, les réceptions et la communication aux utilisateurs. L'IT est responsable de l'intégration, des interfaces, du concept d'autorisations ainsi que de l'exportation et de la sauvegarde des données. La direction de projet mène le plan, la liste des risques, les rapports de statut et l'escalade. Le fournisseur assure l'intégration, le support et les informations sur les versions. Le budget temps de chaque rôle doit être expressément inclus dans la planification – les collaborateurs des départements spécialisés ne sont pas disponibles pour les activités courantes pendant les tests et les formations.

Responsabilité partagée dans le SaaS : avantages et risques

Régler les données, les droits d'accès et la restauration

Les accès sont contrôlés par des contrôles d'accès basés sur les rôles (RBAC) et empêchent les utilisateurs non autorisés d'accéder aux données. À cela s'ajoute la séparation entre les clients : dans une architecture multi-tenant, chaque client ne voit que ses propres données, sécurisées techniquement par exemple via la sécurité au niveau des lignes (Row-Level Security) au niveau de la base de données. Les critères importants pour une solution de sauvegarde sont une gestion simple et un contrôle d'accès basé sur les rôles.

Risques typiques contre lesquels le plan de projet doit prendre des dispositions : suppressions accidentelles et erreurs humaines, initiés malveillants, rançongiciels et cyberattaques qui ciblent de plus en plus les applications SaaS, ainsi qu'erreurs de synchronisation entraînant une perte ou une corruption des données. La responsabilité partagée implique une stratégie propre de sauvegarde et de restauration pour les données SaaS – au lieu de se fier aux sauvegardes du fournisseur.

Il faut ancrer fermement dans le plan de projet un concept d'autorisations avec des rôles définis, un test de restauration avant la mise en production, des règles claires définissant qui peut supprimer et restaurer, la journalisation des actions critiques, les délais de conservation et de suppression, ainsi qu'une exportation ordonnée lors de la sortie d'un service. Sans ces points, on ne sait pas qui agit en cas de besoin.

Points critiques avant la mise en production : données et sécurité

Migration et intégration dans le paysage système existant

L'objectif de la migration est de transférer les applications, les données et les processus métier existants vers le nouvel environnement de manière sûre, structurée et sans perturbations opérationnelles. Cela s'accompagne d'une réduction de la complexité et d'une diminution des dépendances technologiques – les deux pouvant se mesurer au nombre de systèmes remplacés et aux interfaces restantes.

Concrètement, la migration commence par un inventaire des données : quels enregistrements sont nécessaires, où se trouvent-ils aujourd'hui, qui en est le propriétaire, quels champs doivent être attribués et comment ? Suivent ensuite le nettoyage avant la reprise, l'exportation depuis l'ancien système, l'importation, la comparaison et un contrôle documenté des enregistrements. Les interfaces sont connectées via l'API de la solution ; il faut clarifier si l'échange se fait en continu ou par lots et ce qui se passe en cas de panne.

Pendant la transition, un fonctionnement parallèle est mis en place : l'ancien système et la nouvelle solution sont gérés simultanément pendant une période définie. Il faut définir à l'avance la durée, les critères de mise hors service, la responsabilité de la comparaison des données et une solution de repli en cas de blocage de la transition. Après la mise hors service de l'ancien système, les contrats, les licences, les accès et les contrats de maintenance doivent figurer sur la liste de clôture – sinon les coûts et les dépendances perdurent.

Étapes de la migration vers le nouvel environnement SaaS

Après la mise en production : exploitation, coûts et développement ultérieur

Avec le démarrage en production, l'exploitation commence. Le SaaS fonctionne selon un modèle d'abonnement avec des coûts mensuels ou annuels ; ces dépenses récurrentes doivent être intégrées au budget sur toute la durée du contrat, et non seulement pour l'année d'introduction. Des utilisateurs ou des licences supplémentaires peuvent généralement être ajoutés en quelques clics, ce qui fait augmenter les coûts avec le nombre d'utilisateurs.

Pour le pilotage, des indicateurs clés font partie de l'exploitation : utilisateurs actifs, utilisation par processus et cas de support. Les analyses et les tableaux de bord fournissent les données nécessaires. Les nouvelles fonctionnalités sont étendues progressivement et sur la base des retours des utilisateurs – le développement du produit ne s'arrête pas chez le fournisseur à la première version en ligne, et la planification continue donc également de manière continue chez le client.

Les coûts et le temps varient fortement selon l'ampleur. logixc donne des valeurs de référence pour le développement d'un produit SaaS en Suisse : CHF 20'000 à 40'000 et 6 à 10 semaines pour un MVP, CHF 40'000 à 80'000 et 12 à 20 semaines pour une v1.0 complète, CHF 80'000 et plus ainsi que 6 mois et plus pour des variantes Enterprise avec multi-tenant, API et intégrations. Ces chiffres concernent le développement du produit. Lors de l'introduction d'une solution achetée, ce sont plutôt les coûts d'abonnement, d'intégration, de formation et d'exploitation qui s'appliquent ; leur montant dépend de l'ampleur, du nombre d'interfaces et de la taille du groupe d'utilisateurs.