Introduction du SaaS : plan de projet, jalons et responsabilités

Introduire le SaaS ne signifie pas développer un logiciel

SaaS signifie Software as a Service : l'application s'exécute dans le cloud et est fournie via Internet. L'accès se fait par le navigateur ou une application ; aucune installation sur votre propre ordinateur ou serveur 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 et Zoom.

Pour le projet, la tâche change : il ne s'agit pas d'un projet de développement avec sa propre feuille de route produit, mais d'un projet de mise en œuvre et d'intégration. Cela inclut la configuration, le concept d'autorisations, la reprise des données, les interfaces, la formation et la réception. Au sein de l'entreprise utilisatrice, la responsabilité des données – intégrité, conservation et sauvegarde – ainsi que la gestion des accès, les autorisations des utilisateurs et la restauration après un incident restent de son ressort.

La large diffusion ne rend pas la mise en œuvre plus simple : selon Statista, 70 pour cent des entreprises comptant jusqu'à 500 employés et 56 pour cent de toutes les entreprises mondiales utilisent des applications SaaS. Un plan comprenant des décisions, des rôles, des fenêtres de test et des critères de réception est donc réaliste. L'hypothèse selon laquelle un produit standard couvre tous les cas particuliers ne tient pas.

Une autre différence par rapport à l'installation propre : le fournisseur déploie automatiquement les nouvelles versions et fonctionnalités. Les utilisateurs travaillent ainsi toujours avec la version actuelle. La planification des versions propres disparaît du plan de projet ; il reste néanmoins nécessaire de définir des créneaux horaires pour les tests après les mises à jour majeures du fournisseur et d'assurer une communication claire envers les utilisateurs.

Clarifier l'image cible, les processus et les exigences

Avant la décision concernant le produit vient l'analyse de la situation initiale : l'architecture système existante, les processus métier et les exigences organisationnelles sont recensé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é. Elle est ancrée dans la stratégie de l'entreprise et n'est pas uniquement pilotée par l'informatique. Elle fournit une feuille de route pour la modernisation informatique, des décisions d'investissement transparentes et une architecture qui évolue avec l'entreprise.

Il convient de recenser : la cartographie des processus avec les flux concernés, les données associées et les flux de données, les interfaces existantes, les rôles et les niveaux d'autorisation, les exigences concernant le lieu de stockage des données et les langues nécessaires. Il en résulte une image cible avec des critères vérifiables : processus à couvrir, nombre d'utilisateurs, volume de données, cadre budgétaire et délais.

L'image cible est plus qu'une étude préliminaire : elle sert ultérieurement de référence pour la sélection des fournisseurs et de critère de réception après le déploiement. La réduction de la complexité et la minimisation des dépendances technologiques peuvent être mesurées par le nombre de systèmes remplacés et les interfaces restantes.

Sélection de la solution : critères avec référence à la Suisse

Un catalogue de critères empêche que les impressions de démonstration ne dictent la sélection. Il faut vérifier l'étendue fonctionnelle par rapport aux exigences de processus recensées, le stockage des données en Suisse ou dans l'UE, le multilinguisme en DE/EN/FR ainsi que la facturation et les modes de paiement. Le stockage des données en Suisse ou dans l'UE est considéré comme une exigence pour la conformité à la LPD ; DE/EN/FR est la norme pour le marché suisse. Le soutien fourni par le fournisseur lors de la mise en œuvre compte également.

De nombreux clients B2B suisses préfèrent le paiement par virement IBAN. Vérifiez si le fournisseur prend cela en charge et si les factures en CHF incluent la taxe sur la valeur ajoutée suisse. En Suisse, l'assujettissement à la TVA existe dès un chiffre d'affaires annuel de CHF 100'000.

Les critères techniques ont une importance équivalente. Dans une architecture multi-locataire (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 rapports. L'évolutivité compte aussi : des licences supplémentaires peuvent généralement être commandées en quelques clics, ce qui maintient l'effort réduit en cas de croissance ou de changement de personnel.

Pour une comparaison structurée, une matrice d'évaluation pondérée convient : les mêmes questions posées à tous les fournisseurs, évaluation par critère, totalisation ensuite seulement. Un accès de test avec vos propres exemples de données montre si les processus centraux sont réellement couverts. Il faut clarifier par écrit les temps 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 résume seulement ce qui a été évalué auparavant avec vos propres critères.

Critères pondérés pour la sélection des fournisseurs SaaS (Suisse)

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

Une procédure éprouvée passe par 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. Une approche similaire est connue dans le développement SaaS : 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 le début de la suivante.

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

Phase 2 – Architecture et intégration : ici tombent les décisions techniques fondamentales – exploitation multi-locataire ou mono-locataire, concept d'isolation des données, conception API, lieu de stockage des données, modèle d'autorisations et la 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 centrales et des données réelles ; les erreurs, les lacunes et les problèmes d'utilisation sont enregistrés et priorisés. Résultats : cas de test réussis, liste d'erreurs corrigée, documents de formation, données de test migrées. Ce n'est que lorsque les processus centraux fonctionnent dans le 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 par groupe d'utilisateurs. Résultats : démarrage productif avec un nombre d'utilisateurs défini, formations achevées, canal de support fonctionnel.

Phase 5 – Mise à l'échelle : extension à d'autres domaines, modules supplémentaires, automatisation et optimisation des performances. La mise en œuvre ne se termine pas avec la première version live ; le développement du produit continue chez le fournisseur, l'entreprise planifie en conséquence l'exploitation et l'extension.

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 présent et un rôle responsable. Exemples : analyse des processus achevée, sélection du fournisseur approuvée par le mandant, phase de test réussie avec de vrais utilisateurs, démarrage productif, 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 centraux convenus sont parcourus avec des données réelles et si la restauration des données est prouvée – non pas si « l'ambiance est bonne ». Si un critère n'est pas atteint, les conséquences doivent être fixées à l'avance : renégociation, formation complémentaire, nouveau cycle de test ou abandon du projet.

La dimension temporelle dépend fortement du périmètre. Celui qui n'introduit qu'un domaine central a besoin de moins d'étapes de migration, d'interfaces et de formations que pour une gamme 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.

Séquence chronologique des jalons dans le projet SaaS

Qui porte 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 en grande partie à l'entreprise utilisatrice. De nombreuses entreprises supposent à tort que le fournisseur protège aussi leurs données. En réalité, l'intégrité, la conservation et la sauvegarde des données restent à la charge du client – ainsi que la gestion des accès, les autorisations des utilisateurs et la restauration des données.

Du côté du fournisseur figurent la fourniture 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 figurent la responsabilité des données, le concept d'autorisations, la sauvegarde propre des données SaaS, le plan d'urgence et la conformité.

Il est possible d'en déduire des rôles de projet concrets : le côté mandant décide du budget et des validations de jalons. Les départements métiers fournissent les processus, les cas de test, les réceptions et la communication aux utilisateurs. L'informatique 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 gère le plan, la liste des risques, les rapports de statut et l'escalade ; le côté fournisseur fournit l'onboarding, le support et les informations sur les versions.

Le budget temps de chaque rôle doit être explicitement inclus dans la planification. Les collaborateurs des départements métiers ne sont pas disponibles pour les affaires courantes pendant les tests et la formation.

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. S'y ajoute la séparation entre clients : dans une architecture multi-locataire, chaque client ne voit que ses propres données, techniquement sécurisées par exemple via la sécurité au niveau des lignes (Row-Level Security) au niveau de la base de données. Des 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, ransomwares et cyberattaques qui ciblent de plus en plus les applications SaaS, ainsi que des erreurs de synchronisation entraînant une perte ou une corruption de données. De la responsabilité partagée découle une stratégie propre de sauvegarde et de récupération pour les données SaaS – au lieu de se fier aux sauvegardes du fournisseur.

Doivent être fermement ancrés dans le plan de projet un concept d'autorisations avec des rôles définis, un test de restauration avant le go-live, des règles claires indiquant qui peut supprimer et restaurer, la journalisation des actions critiques, les durées de conservation et de suppression ainsi qu'un export ordonné en cas de départ d'un service. Sans ces points, il reste ouvert de savoir qui agit en cas d'urgence.

Points critiques avant le go-live pour l'introduction du SaaS

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 dans le nouvel environnement de manière sûre, structurée et sans perturbations opérationnelles. Cela implique la réduction de la complexité et la diminution des dépendances technologiques. Les deux peuvent être mesurés par le nombre de systèmes remplacés et les interfaces restantes.

En pratique, la migration commence par un inventaire des données : quels jeux de données sont nécessaires, où se trouvent-ils aujourd'hui, qui est propriétaire, quels champs doivent être attribués comment ? Suivent ensuite le nettoyage avant la reprise, l'export depuis l'ancien système, l'import, la comparaison et un contrôle documenté des jeux de données. 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 maintenu : l'ancien système et la nouvelle solution sont gérés simultanément pendant une période définie. À définir à l'avance : la durée, les critères pour la mise hors service, la responsabilité pour la comparaison des données et une voie de repli si la transition bloque. Après la mise hors service de l'ancien système, les contrats, licences, accès et contrats de maintenance figurent sur la liste de clôture – sinon les coûts et les dépendances persistent.

Après le go-live : exploitation, coûts et développement continu

Avec le démarrage productif commence l'exploitation. Le SaaS fonctionne selon un modèle d'abonnement avec des coûts mensuels ou annuels ; ces dépenses récurrentes doivent figurer au budget sur toute la durée, pas seulement l'année de mise en œuvre. Des utilisateurs ou licences supplémentaires peuvent généralement être ajoutés en quelques clics, ce qui fait croître 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 rapports et tableaux de bord fournissent les données pour cela. De nouvelles fonctions sont étendues progressivement et sur la base des retours des utilisateurs. Le développement du produit ne s'arrête pas chez le fournisseur avec la première version live ; en conséquence, la planification se poursuit également chez le client.

Les coûts et l'effort temporel varient considérablement selon le périmètre. logixc cite des valeurs indicatives pour le développement d'un produit SaaS en Suisse : CHF 20'000 à 40'000 et 6 à 10 semaines pour un MVP. Pour une v1.0 complète, ce sont CHF 40'000 à 80'000 et 12 à 20 semaines. Les variantes Enterprise avec multi-locataire, API et intégrations coûtent CHF 80'000 et plus ainsi que 6 mois et plus.

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. Décisifs pour leur montant sont le périmètre, le nombre d'interfaces et la taille du groupe d'utilisateurs.