Implémenter le SaaS : plan de projet, jalons et responsabilités

Implémenter 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 d'introduction 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 l'introduction plus simple : selon Statista, 70 % des entreprises comptant jusqu'à 500 employés et 56 % de toutes les entreprises mondiales utilisent des applications SaaS. Un plan réaliste comprenant des décisions, des rôles, des fenêtres de test et des critères de réception est donc indispensable. 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 interne des versions 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 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 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 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 lors des démonstrations ne déterminent le choix. Il faut vérifier l'étendue des fonctionnalités par rapport aux exigences processuelles 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 l'introduction compte également.

De nombreux clients B2B suisses préfèrent le paiement par virement IBAN. Vérifiez si le fournisseur prend en charge cette option et si les factures sont émises en CHF avec la TVA 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 réservées en quelques clics, ce qui maintient les efforts réduits en cas de croissance ou de changement de personnel.

Pour une comparaison structurée, une matrice d'évaluation pondérée est appropriée : poser les mêmes questions à tous les fournisseurs, évaluer chaque critium, puis seulement faire la somme. 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 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é auparavant selon vos propres critères.

Critères des fournisseurs SaaS avec référence à la 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 comparable 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 que la suivante ne commence.

Phase 1 – Concept et périmètre : les résultats sont l'analyse des processus, la liste des exigences, le concept global, l'estimation des volumes (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 de l'API, lieu de stockage des données, modèle d'autorisation 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, lacunes et 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 si les processus centraux fonctionnent lors du 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. L'introduction ne s'arrête pas à 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 les efforts de test.

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 principalement à 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 – tout comme 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'autorisation, 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'autorisation 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.

Avantages et risques lors de l'introduction du SaaS

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 mesures : 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 des données. De la responsabilité partagée découle une propre stratégie de sauvegarde et de récupération 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'autorisation avec des rôles définis, un test de restauration avant le go-live, 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, il reste ouvert de savoir qui agit en cas d'urgence.

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

L'objectif de la migration est de transférer les applications existantes, les données et les processus métier de manière sûre, structurée et sans perturbations opérationnelles vers le nouvel environnement. 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 en est le propriétaire, comment les champs doivent-ils être attribués ? Suivent ensuite le nettoyage avant la reprise, l'exportation depuis l'ancien système, l'importation, 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 mis en place : l'ancien système et la nouvelle solution sont exploités simultanément pendant une période définie. Il faut fixer à l'avance la durée, les critères pour l'arrêt, la responsabilité pour la comparaison des données et une voie de retour en cas de blocage de la transition. Après l'arrêt de l'ancien système, les contrats, licences, accès et contrats de maintenance doivent figurer 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 ultérieur

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 d'introduction. 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 doivent être intégrés à l'exploitation : utilisateurs actifs, utilisation par processus et cas de support. Les rapports et 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 avec la première version live ; en conséquence, la planification se poursuit également chez le client.

Coûts et effort temporel varient fortement selon le périmètre. logixc mentionne 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, il s'agit de 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. Leur montant dépend essentiellement du périmètre, du nombre d'interfaces et de la taille du groupe d'utilisateurs.