SaaS, hébergement infogéré ou auto-hébergement : choisissez en fonction de la répartition du travail

Commencez par définir le rôle que l’application doit remplir

Choisir où faire fonctionner une application ne revient pas seulement à choisir entre le cloud d’un fournisseur et votre propre serveur. Il s’agit de décider qui exploitera les différentes couches nécessaires au bon fonctionnement de l’application, et qui prendra les décisions relatives aux données, aux accès, à la configuration et à la reprise d’activité.

Commencez par décrire la mission de l’application, les systèmes auxquels elle doit se connecter, les personnes qui doivent y accéder et les conséquences d’une indisponibilité. Dressez ensuite la liste des tâches opérationnelles que votre équipe peut réellement prendre en charge. Un modèle qui paraît simple au moment de l’inscription peut tout de même demander des efforts au client en matière d’identité, de gestion des données, d’intégrations ou de rétablissement du service.

Ces appellations sont des points de départ utiles, mais ne constituent pas des contrats complets. Le périmètre du SaaS, de l’hébergement infogéré et de l’auto-hébergement peut varier selon le fournisseur ou l’accord conclu. Avant de vous fier à une supposition, vérifiez les responsabilités dans la documentation et les contrats du fournisseur.

• Quel processus métier dépend de l’application, et quelles seraient les conséquences d’une panne ou d’une perte de données ?
• Devez-vous modifier l’application, son déploiement ou sa configuration sous-jacente ?
• Quelles intégrations, règles de contrôle des identités et exigences de gestion des données sont indispensables ?
• Qui, dans votre équipe, sera responsable de l’administration, du suivi auprès du fournisseur et des décisions de reprise ?

Définissez les modèles selon la personne qui exploite chaque couche

Le SaaS désigne généralement une application fournie et exploitée par un prestataire. Celui-ci exploite habituellement le service et l’infrastructure sous-jacente ; les clients utilisent l’application et gèrent leurs propres utilisateurs, paramètres et processus métier. La répartition exacte des responsabilités, notamment pour l’export des données, l’identité, les sauvegardes et la réponse aux incidents, dépend du service.

L’hébergement infogéré signifie qu’un prestataire prend en charge certaines tâches d’hébergement ou d’infrastructure pour une application, tandis que le client reste responsable d’au moins une partie des décisions liées à l’application et à l’organisation. Cette appellation ne définit pas de frontière universelle. Un prestataire peut gérer le déploiement et les opérations courantes du service ; un autre peut se limiter à une couche d’hébergement plus restreinte. Demandez ce qui est inclus au lieu de vous fier à l’étiquette.

Avec l’auto-hébergement, l’organisation fait fonctionner l’application sur une infrastructure qu’elle contrôle ou dont elle organise la mise à disposition. Elle bénéficie ainsi d’un contrôle plus direct sur le déploiement et la configuration, mais assume aussi davantage de tâches opérationnelles, par l’intermédiaire de son équipe ou de prestataires. Le recours à un fournisseur d’infrastructure cloud ne transforme pas automatiquement une application en SaaS : votre organisation peut toujours être responsable de l’exploitation de l’application.

Règle générale utile : distinguez l’application de l’infrastructure sur laquelle elle fonctionne. Le fait qu’un prestataire exploite une couche ne signifie pas, à lui seul, qu’il prend en charge toutes les tâches des couches supérieures ou inférieures.

• SaaS : le fournisseur exploite généralement le service applicatif ; le client reste responsable de son utilisation, de ses utilisateurs, de ses choix concernant les données et de sa gouvernance.
• Hébergement infogéré : le fournisseur prend en charge les tâches d’hébergement convenues ; le client conserve les responsabilités qui ne sont pas explicitement incluses.
• Auto-hébergement : l’organisation organise l’exploitation de l’application et de son environnement, directement ou par l’intermédiaire de ses propres prestataires.

Utilisez une matrice des responsabilités et vérifiez les limites

La matrice ci-dessous est un outil de discussion, et non une promesse concernant tous les fournisseurs. Le terme « généralement » désigne une hypothèse de départ courante, pas un service garanti. Pour l’hébergement infogéré en particulier, les responsabilités varient beaucoup. Demandez au fournisseur de compléter la même matrice pour l’application et l’offre que vous envisagez.

Certaines tâches sont partagées. Un fournisseur peut, par exemple, gérer les sauvegardes de l’infrastructure tandis que le client décide des données à conserver, des personnes autorisées à y accéder et de la marche à suivre en cas de restauration. La présence d’une fonction de sauvegarde ne vaut pas plan de reprise testé.

• Exploitation de l’infrastructure — SaaS : généralement le fournisseur ; hébergement infogéré : le fournisseur pour le périmètre d’hébergement prévu au contrat ; auto-hébergement : l’organisation ou les fournisseurs d’infrastructure qu’elle a choisis.
• Installation et mises à jour de l’application — SaaS : le fournisseur contrôle généralement les mises à jour du service, selon son processus de publication ; hébergement infogéré : cela varie, demandez qui planifie, applique et valide les mises à jour ; auto-hébergement : l’organisation les planifie et les applique, sauf si elle délègue cette tâche.
• Sauvegardes — SaaS : demandez quelles données sont sauvegardées, pendant combien de temps et si le client peut demander une restauration ; hébergement infogéré : vérifiez le périmètre des sauvegardes, leur fréquence, leur durée de conservation et la responsabilité de la restauration ; auto-hébergement : l’organisation doit organiser et surveiller les sauvegardes, ou en confier la gestion par contrat.
• Accès et identité — tous les modèles : le client doit définir les personnes qui doivent avoir accès et gérer les autorisations liées à son activité. Demandez quels contrôles d’identité le service prend en charge et quelle partie gère les comptes au niveau de la plateforme.
• Données et gouvernance — tous les modèles : le client doit décider quelles données intégrer à l’application, qui peut les utiliser et quelles politiques s’appliquent. Vérifiez directement auprès du fournisseur ses engagements, l’emplacement des données et les conditions de leur traitement.
• Reprise — tous les modèles : convenez de la personne chargée de détecter et de signaler les incidents, de celle qui lance la reprise, des options disponibles et des actions attendues du client. Ne présumez pas que la responsabilité de l’hébergement garantit un délai ou un résultat de reprise.
• Configuration et intégrations — SaaS : limitées aux paramètres et interfaces proposés par le service ; hébergement infogéré : peut offrir davantage de flexibilité au niveau du déploiement, selon le service ; auto-hébergement : permet généralement le contrôle le plus direct, avec les tâches opérationnelles correspondantes.

Comparez les compromis au-delà de la charge opérationnelle

Le contrôle et les efforts demandés évoluent généralement en sens inverse, mais pas toujours de façon parfaite. Le SaaS peut réduire le besoin d’exploiter la pile applicative, tout en limitant les choix de déploiement ou les possibilités de personnalisation. L’auto-hébergement peut offrir un contrôle plus direct, mais ce contrôle n’est utile que si quelqu’un peut maintenir l’environnement. L’hébergement infogéré permet de déléguer des tâches opérationnelles définies sans nécessairement transférer le contrôle de l’application ou la responsabilité des décisions métier.

Tenez également compte des dépendances et de la portabilité. Un service peut s’appuyer sur des configurations, intégrations, fonctions d’identité ou formats de données propres à un fournisseur. Passer d’un modèle à un autre peut demander davantage que la simple copie d’une base de données : les fichiers de l’application, la configuration, les identifiants, les intégrations et les accès des utilisateurs peuvent aussi nécessiter une attention particulière. Posez ces questions avant de choisir, et pas seulement au moment de prévoir votre départ.

• Contrôle : quelles décisions relatives à l’application, au déploiement et à la configuration devez-vous conserver ?
• Personnalisation : le produit permet-il les changements nécessaires ou faut-il accéder à l’environnement de l’application ?
• Effort opérationnel : qui s’occupera des mises à jour courantes, de la surveillance, du contrôle des sauvegardes, du dépannage et de la coordination de la reprise ?
• Dépendances : quels services d’identité, de stockage, de messagerie, d’API ou autres doivent continuer de fonctionner pour que l’application reste utile ?
• Portabilité : pouvez-vous obtenir des copies utilisables de vos données et de votre configuration, et quels éléments faudrait-il reconstruire après une migration ?
• Responsabilité : en cas de problème, disposez-vous d’un interlocuteur identifié chez le fournisseur et d’une marche à suivre claire pour le client ?

Repérez les exigences susceptibles d’exclure un modèle

Certaines exigences sont des critères éliminatoires plutôt que de simples préférences. Si un service ne peut satisfaire une exigence d’intégration, de traitement des données ou de reprise, une charge opérationnelle réduite ne compensera pas cette lacune. Commencez par noter les conditions obligatoires, puis comparez les options restantes.

Les exigences de gouvernance peuvent porter sur l’approbation des accès, la possibilité de réaliser des audits, le traitement des données ou les personnes autorisées à administrer le service. Les détails dépendent de votre organisation et du fournisseur ; ne supposez pas que le modèle de déploiement garantit à lui seul la conformité. Validez les contrôles concernés et les engagements contractuels auprès du fournisseur et, le cas échéant, de vos spécialistes internes.

Les besoins en matière de reprise méritent une attention particulière. Définissez les données et les fonctions à restaurer, les personnes autorisées à valider une restauration et les preuves nécessaires pour établir que le processus fonctionne. Si les réponses du fournisseur ne correspondent pas à vos exigences, vous devrez peut-être revoir le modèle ou le fournisseur.

• Le SaaS peut ne pas convenir si un déploiement ou une personnalisation indispensable n’est pas disponible, ou si les modalités de gestion des données, des intégrations ou des accès ne répondent pas à une exigence obligatoire.
• L’hébergement infogéré peut ne pas convenir si votre équipe a besoin que le fournisseur assume des responsabilités qu’il ne prendra pas en charge, ou si la répartition entre les opérations du fournisseur et celles du client reste floue.
• L’auto-hébergement peut ne pas convenir si personne ne peut assumer clairement la responsabilité des mises à jour, des sauvegardes, de la gestion des accès et de la reprise, ou si l’organisation ne peut pas maintenir ces efforts dans la durée.
• Aucun modèle ne conviendra forcément si le fournisseur ne peut pas expliquer comment exporter vos données, comment les accès sont contrôlés et ce qui se passe à la fin du service.

Évaluez les compromis à partir d’une charge de travail réaliste

Imaginez qu’une petite équipe opérationnelle souhaite une application de suivi de projets en interne. Le personnel a besoin d’un accès par navigateur, d’une connexion à un système d’identité existant ou à un flux de notifications, ainsi que d’un moyen fiable de récupérer les enregistrements. L’équipe ne dispose pas de spécialiste de l’infrastructure en interne.

Le SaaS pourrait convenir à l’équipe si le service prend en charge le flux de travail et les contrôles nécessaires, et si les modalités d’export et de reprise des données du fournisseur sont acceptables. L’hébergement infogéré pourrait convenir si l’équipe a besoin d’un déploiement particulier de l’application et si un fournisseur s’engage clairement à prendre en charge les tâches d’infrastructure qu’elle ne peut pas gérer elle-même. L’auto-hébergement pourrait également être envisageable si l’organisation dispose d’un opérateur désigné ou d’un soutien contractuel, et si elle juge que le contrôle nécessaire justifie les efforts continus associés.

Aucune de ces conclusions ne découle automatiquement de la description de la charge de travail. L’équipe doit tester l’intégration réelle, clarifier l’administration des comptes, examiner les modalités de sauvegarde et de restauration et estimer les tâches qui lui incomberont. Cet exercice est utile, car il transforme des souhaits comme « nous voulons garder le contrôle » ou « nous voulons une solution gérée » en exigences vérifiables.

• Dressez la liste des fonctionnalités et intégrations indispensables au flux de travail.
• Désignez la personne responsable de l’administration de l’application et de la modification des accès.
• Demandez à chaque fournisseur de décrire le déroulement d’une mise à jour courante et d’une demande de récupération de données.
• Notez les actions que l’équipe devra entreprendre en cas de panne, de départ d’un membre du personnel ou de migration planifiée.
• Écartez les options qui ne satisfont pas aux exigences obligatoires avant de comparer leur simplicité d’utilisation.

Demandez aux fournisseurs qui prend en charge les opérations courantes

Lors d’un échange utile avec un fournisseur, demandez-lui de décrire des procédures concrètes, et pas seulement d’énumérer les fonctionnalités incluses. Demandez ce qui se passe lors de la maintenance ordinaire comme en cas d’imprévu. Dans la mesure du possible, demandez au fournisseur de distinguer ce qu’il réalise, ce qu’il recommande et ce qu’il attend du client.

Pour un déploiement géré par Airbip, Airbip indique que son service exécute les instances applicatives sous forme de charges de travail Docker sur des serveurs cloud Airbip. Les fonctionnalités annoncées comprennent le routage automatisé et les certificats TLS via Traefik et Let’s Encrypt, les vérifications DNS, la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces fonctionnalités ne répondent pas à toutes les questions de responsabilité : vérifiez directement le périmètre et la durée de conservation des sauvegardes, les étapes de restauration, les responsabilités en matière d’accès et de données ainsi que toute autre exigence. Consultez le site Web actuel d’Airbip pour connaître les offres et conditions commerciales en vigueur.

• Qui installe et applique les mises à jour de l’application ? Le client peut-il choisir le moment de leur installation ?
• Quelles opérations de surveillance et de dépannage sont incluses, et quels événements exigent une action du client ?
• Que comprennent exactement les sauvegardes, combien de temps sont-elles conservées et comment se déroule une restauration ?
• Qui gère les comptes applicatifs, les accès administrateur et l’intégration de l’identité ?
• Quelles données et configurations le client peut-il exporter, sous quel format et selon quelle procédure ?
• Qui communique pendant un incident, et quelles informations ou actions sont attendues du client ?
• Quelles intégrations, personnalisations ou modifications de déploiement sont prises en charge, et lesquelles sont hors périmètre ?
• Où les limites de service et les exclusions sont-elles documentées ?

Planifiez l’export des données, la migration et la fin du service

Il est plus facile d’évaluer la portabilité avant d’adopter un service. Renseignez-vous sur l’export des enregistrements et des fichiers, sur la possibilité de transférer la configuration et les informations sur les utilisateurs, ainsi que sur les intégrations à recréer. Vérifiez que l’export est dans un format utilisable avec votre prochaine solution ; la présence d’une fonction d’export ne garantit pas, à elle seule, une migration simple.

Établissez un plan de sortie adapté à l’importance de l’application. Déterminez qui demandera l’export, qui le vérifiera, comment gérer les accès pendant la transition et ce qu’il adviendra des copies conservées par le fournisseur que vous quittez. Vérifiez dans les conditions actuelles du fournisseur les délais, frais et conditions applicables au lieu de vous fier à des suppositions.

Le modèle adapté est celui dont les limites opérationnelles, le niveau de contrôle et les modalités de sortie correspondent à vos exigences et à vos capacités. Le SaaS, l’hébergement infogéré et l’auto-hébergement peuvent tous être pertinents. La question pratique n’est pas de savoir quelle appellation semble la plus sûre, mais si chaque responsabilité importante a un propriétaire.

• Demandez un exemple ou une description de l’export des données avant de vous engager.
• Identifiez les données de l’application, les fichiers, la configuration, les comptes utilisateurs et les intégrations susceptibles de devoir être transférés.
• Déterminez qui validera les données exportées et ce qui constituera une transition réussie.
• Examinez avec le fournisseur les conditions de résiliation du service, de conservation des données et de suppression.
• Tenez à jour un registre des responsabilités qui désigne un responsable côté client pour chaque tâche que le fournisseur n’accepte pas explicitement.