Partagé, non exposé : comment les clouds de test sont redéfinis

L'évolution des clouds d'appareils : du public au privé puis au partagé

En tant que chef de produit responsable de la mise en œuvre des fonctionnalités administratives au sein de Digital.ai Dans le cadre des tests de plateformes, j'envisage l'infrastructure sous un angle particulier : l'équilibre entre disponibilité et contrôle. Mon rôle, celui d'administrateur cloud, est celui de garant de l'accès aux ressources. Il alloue les ressources, gère les permissions des utilisateurs et, surtout, veille à ce que les ressources soient disponibles lorsque les équipes de test en ont besoin.

Au fil des ans, notre secteur a considérablement évolué. Nous sommes passés d'une maîtrise totale du matériel physique à l'immense flexibilité du cloud public. Mais aucun de ces extrêmes n'a résolu le véritable problème. Aujourd'hui, nous empruntons une voie différente, qui remet en question la fausse dichotomie que le secteur a acceptée trop longtemps.

L'avenir ne se résume pas à choisir entre « confinement » et « ouverture à tous ». Il s'agit d'un troisième voie : Instance partagée

Permettez-moi de vous expliquer comment nous en sommes arrivés là, et pourquoi cette distinction est plus importante que la plupart des fournisseurs ne veulent bien l'admettre.

Phase 1 : L'ère de « l'attachement au matériel » (en interne et sur site)

On se souvient tous du modèle traditionnel : le laboratoire interne de maintenance des appareils. Les câbles USB qui serpentent sur les bureaux. Les batteries gonflées des appareils mobiles qu’il faut remplacer tous les six mois. Les mises à jour manuelles du système d’exploitation qui prennent des après-midi entières. Cet iPhone 6 qui, miraculeusement, fonctionnait encore alors que tous les autres étaient bons pour la casse.

Il y avait quelque chose de satisfaisant dans ce contrôle tangible : on pouvait littéralement aller chercher l’appareil qui posait problème. Mais la charge opérationnelle était écrasante.

Pour nos clients soucieux de la sécurité, notamment dans les secteurs bancaire et de la défense, nous avons développé des solutions formelles sur site et hors ligne. Dans ces configurations, l'infrastructure est totalement isolée, garantissant ainsi un contrôle total des données.

Les appareils ne se connectent jamais à Internet. Les données de test ne quittent jamais le bâtiment.

Pourquoi cela est apparu

Les applications bancaires qui traitent des données financières, les applications de santé qui gèrent les dossiers des patients et les applications gouvernementales qui contiennent des informations classifiées ne pouvaient pas fonctionner sur une infrastructure où des tests effectués par une autre entreprise auraient pu utiliser le même appareil quelques heures auparavant.

La réponse de l'industrie était simple : « Ces appareils vous appartiennent et à vous seul, isolés dans votre environnement. Personne d'autre ne doit les toucher. »

Cela a répondu à de réels besoins.

• Isolation complète des dispositifs et des données pour les applications traitant des informations réglementées ou classifiées.
• Configuration d'infrastructure personnalisée pour répondre aux exigences internes en matière de sécurité, de réseau et de conformité
• Résidence et souveraineté des données garanties, sans dépendance vis-à-vis des ressources publiques partagées
• Déploiements isolés pour les environnements qui ne peuvent absolument pas se connecter à Internet.

Le problème que cela a créé

Voici ce que j'ai constaté en gérant ces environnements : cela a résolu le problème de sécurité, mais en a créé un nouveau : le problème économique.

• Coût total élevéLes organisations consacraient beaucoup de temps, de ressources et d'argent à l'entretien de l'infrastructure.
• Accès lent aux nouveaux appareilsJ'ai vu des clients attendre trois mois pour pouvoir tester l'iPhone 15 après sa sortie. L'achat devait être approuvé par la direction, le service des achats devait passer commande, et le personnel informatique devait le configurer et l'ajouter au laboratoire. Pendant ce temps, leurs utilisateurs téléchargeaient déjà leur application sur le dernier iPhone.

Les solutions sur site offraient aux entreprises la sécurité dont elles avaient besoin, mais à un coût qui ne pouvait pas évoluer au rythme de la couverture des appareils, elle-même incapable de suivre la fragmentation du marché.

Pourtant, pour les charges de travail véritablement sensibles, cela reste valable. Les solutions hors ligne et sur site ne disparaîtront pas ; elles sont indispensables pour les données classifiées et les scénarios soumis à des restrictions légales. Mais elles ne devraient pas constituer la solution par défaut pour tous les besoins de test.

Phase 2 : La bifurcation SaaS (cloud public vs. cloud dédié)

Avec le passage du marché au SaaS, celui-ci s'est scindé en deux options binaires. Aucune ne répond pleinement aux besoins des administrateurs cloud d'entreprise modernes qui cherchent à concilier sécurité, couverture et coût.

Option 1 : Le cloud public

Les clouds publics pour appareils partagés sont apparus comme la première solution à un problème devenu économiquement insoluble : les développeurs ne pouvaient pas se permettre d’acheter tous les appareils que possédaient leurs utilisateurs.

Les appareils sont attribués dynamiquement selon le principe du premier arrivé, premier servi, avec un contrôle limité, et partagés entre tous les clients de la plateforme.

Pourquoi cela est apparu

Au début des années 2010, la fragmentation du marché mobile a explosé. Android lançait des dizaines de nouveaux appareils chaque trimestre, tandis qu'iOS ajoutait de nouveaux modèles chaque année. Tester manuellement son application sur des appareils physiques est devenu économiquement impossible pour toutes les entreprises, à l'exception des plus grandes.

Les clouds publics ont représenté une avancée majeure : un accès instantané à des centaines d’appareils sans achat de matériel.

Paiement à l'utilisation. Aucune installation. Il suffit de cliquer et de tester.

Pour les startups et les équipes de développement dynamiques, cela a été une véritable transformation.

Cela a répondu à de réels besoins.

• Élimination du besoin d'acheter et d'entretenir des laboratoires d'appareils physiques
• Permet une validation rapide et à la demande, sans configuration ni planification d'infrastructure.
• Rendre la couverture étendue des appareils économiquement accessible, même avec des budgets limités.

Les limitations qui sont apparues

Mais à mesure que les entreprises adoptaient ces plateformes, des problèmes sont apparus, que j'ai entendus à maintes reprises dans les conversations avec les clients :

• Contrôle limité« Notre application nécessite des configurations VPN et réseau spécifiques pour se connecter aux environnements internes. Les dispositifs de cloud public s'appuient sur des configurations réseau standardisées qui ne prennent pas en charge cette fonctionnalité. »
• Problèmes de disponibilité« Lorsqu’Apple sort un nouvel iPhone, la demande explose instantanément. Nous nous retrouvons à faire la queue pendant les périodes de test critiques. »
• Lacunes en matière de conformité« Notre équipe de sécurité a examiné l'architecture et l'a rejetée. Une infrastructure publique mutualisée n'est pas acceptable pour les applications traitant des données financières sensibles. »

Les clouds publics ont démocratisé les tests mobiles, mais ils n'ont pas été conçus pour répondre aux exigences de sécurité et de contrôle des entreprises.

Option 2 : Le cloud dédié

Pour combler la faille de sécurité, le secteur s'est standardisé sur les offres de cloud dédié (privé). Il s'agit d'environnements mono-locataires où les appareils sont réservés exclusivement à un seul client.

Des appareils réservés exclusivement à un seul client, offrant un contrôle total sans avoir à gérer l'infrastructure du laboratoire.

Cela a répondu à de réels besoins.

• Accès à un environnement cloud privé et mono-locataire dédié à votre organisation.
• Répondre aux exigences de sécurité et réglementaires grâce à un isolement complet.
• Conserver un contrôle total sur les appareils et les configurations afin d'optimiser les scénarios de test.
• Réduire les frais généraux opérationnels liés à la maintenance des laboratoires, aux mises à niveau et à l'administration informatique.
• Cela offrait aux entreprises le niveau de sécurité dont elles avaient besoin, mais héritait de certains problèmes économiques inhérents aux solutions sur site.

Les limitations qui sont apparues

• Le coût continu des appareils dédiés entraîne une diversité limitée des appareils et une couverture de test incomplète.
• L'attribution restrictive des appareils, en particulier pendant les périodes de pointe telles que les tests de pré-lancement ou le débogage spécifique à un appareil, réduit la flexibilité des tests et peut entraîner des retards de mise sur le marché.

Le décalage : ce dont les clients avaient réellement besoin

À ce moment-là, nous n'avions plus que deux options extrêmes :

• Public modeCouverture des appareils abordable, accessible et diversifiée, mais problèmes de sécurité et contrôle limité.
• DédiéSécurisé, contrôlé, conforme, mais coûteux et variété d'appareils limitée.

Mais lorsque je me suis entretenu avec les clients et que je les ai interrogés sur leurs flux de travail de test réels, ils ont décrit des besoins qui ne correspondaient à aucun des deux extrêmes :

« Notre pipeline CI/CD exécute des tests fonctionnels sur 50 appareils toutes les heures. Ces tests doivent s'exécuter sur notre réseau privé via notre configuration VPN, rapidement, et permettre la réutilisation des configurations d'appareils entre les suites de tests. Les clouds publics ne le permettent pas, et les appareils dédiés sont trop coûteux à mettre à l'échelle. »

« Nous utilisons des appareils dédiés pour les tests de production avec de vraies données clients. Mais pour le développement, nos équipes ont simplement besoin de valider rapidement les correctifs de bugs sur une large gamme d'appareils. Elles n'ont pas besoin de ressources dédiées, mais d'une couverture étendue. »

Le schéma était clair : Les clients avaient besoin d'un espace intermédiaire entre public et dédié..

Ils avaient besoin de :

• Économie des infrastructures partagées avec accès à la demande aux appareils
• Couverture étendue des appareils et des systèmes d'exploitation, comparable aux clouds publics
• Sécurité et isolation de niveau entreprise, sans propriété exclusive des appareils
• Contrôle total du réseau, y compris les configurations VPN et de site à site
• Exécution fiable de suites de tests à grande échelle, sans interruption de configuration ni de nettoyage entre les exécutions.

L'industrie avait présenté le problème comme un choix binaire. Cette vision était erronée, et c'est à partir de là que nous avons commencé à construire quelque chose de différent.

Phase 3 : Appareils partagés dans des clouds privés – La troisième voie

C'est ici que Digital.ai Tests Ces dernières années, nous avons mis l'accent sur l'innovation. Non pas pour nous démarquer à tout prix, mais parce que nous avons écouté les besoins réels de nos clients et cherché à répondre à un besoin concret.

Ce que cela signifie

Les appareils sont attribués dynamiquement selon le principe du premier arrivé, premier servi, mais offrent un contrôle et une flexibilité accrus par rapport aux appareils publics. Ils conviennent à l'exécution de séries de tests volumineuses, nécessitant des configurations spécifiques (par exemple, la même configuration VPN que les appareils dédiés) et une utilisation non perturbatrice.

Vous bénéficiez des avantages économiques d'une utilisation partagée tout en profitant du niveau de sécurité d'un environnement privé.

Pourquoi cela est apparu

Trois forces ont convergé pour rendre ce modèle à la fois possible et nécessaire :

1. La technologie de sécurité du cloud a atteint sa maturité.

L'architecture de cloud privé a évolué au point de permettre une véritable isolation au sein d'une infrastructure mutualisée. Vos appareils, configurations réseau et données restent totalement séparés de ceux des autres clients, même si l'infrastructure cloud sous-jacente est partagée.

Ce niveau d'isolation n'était pas réalisable de manière fiable en 2015. Mais aujourd'hui, il est devenu la norme dans l'architecture cloud d'entreprise.

2. Intensification des pressions sur les coûts

Les équipes souhaitaient bénéficier des mêmes garanties de sécurité tout en optimisant les coûts d'utilisation. L'ancienne réponse, « parce que la sécurité l'exige », n'était plus satisfaisante.

3. Diversification des besoins en matière de tests

Aujourd'hui, les équipes n'ont plus un seul type de test, mais plusieurs charges de travail, chacune avec des exigences différentes :

• Tests de production à haute sécurité utilisant de vraies données clients (nécessite des ressources dédiées)
• Tests fonctionnels CI/CD à grande échelle avec des données synthétiques (privilégiant l'échelle et la couverture à l'exclusivité)
• Tests de compatibilité à grande échelle sur des centaines de combinaisons d'appareils et de systèmes d'exploitation (non rentables sur des appareils dédiés uniquement)
• Validation quotidienne des correctifs de bogues (nécessite un accès rapide et varié, mais pas une disponibilité garantie)

Une infrastructure unique, qu'elle soit publique ou dédiée, ne reflète pas la manière dont les tests sont réellement effectués aujourd'hui.

Ce que cela signifie pour votre stratégie de test

Si vous évaluez aujourd'hui les options de cloud pour appareils, je vous invite à rejeter complètement l'opposition « public vs privé ». Elle est dépassée et ne reflète pas la réalité des tests modernes.

Fondez plutôt votre décision sur le fonctionnement réel de vos équipes. Pour vous aider à trouver les réponses, voici quelques questions pertinentes à vous poser :

1. Quels sont vos besoins réels en matière de charge de travail ?

• Toutes les charges de travail traitent-elles des données sensibles ou réglementées, ou seulement certaines d'entre elles ?
• Avez-vous besoin d'une disponibilité garantie des appareils en permanence, ou seulement pendant des périodes définies ?
• Vos tests dépendent-ils de configurations d'appareils persistantes, ou nécessitent-ils des environnements propres à chaque exécution ?

La plupart des équipes, lorsqu'elles établissent réellement un plan, découvrent qu'elles ont un mélange.

2. Est-il possible de séparer les charges de travail en fonction des exigences de sécurité ?

• Haute sécurité → SaaS dédié ou sur site (données de production, applications réglementées ou à accès restreint)
• Sécurité moyenne → Appareils partagés au sein d'une instance privée (tests fonctionnels, CI/CD, compatibilité)
• Sécurité faible → Appareils publics ou partagés au sein d'une instance privée (développement préliminaire, validation non sensible)

Le principal enseignement à retenir : toutes les charges de travail de test ne nécessitent pas le niveau de sécurité le plus élevé.

Conclusion : L’évolution, et non la révolution

Le passage du public au privé puis au partagé n'a pas été motivé par l'innovation des fournisseurs pour le simple plaisir d'innover. Il a été dicté par les besoins des clients et les forces du marché que le secteur ne pouvait ignorer.

Le partage d'appareils au sein d'un environnement SaaS privé est apparu parce que les organisations devaient trouver un équilibre entre des impératifs économiques incontournables, une diversité d'appareils indispensable aux tests et une sécurité qu'elles ne pouvaient se permettre de sacrifier.

At Digital.ai Nos tests nous ont appris que l'avenir de l'infrastructure cloud pour appareils ne réside pas dans le choix d'un modèle de déploiement unique. Il s'agit plutôt de concevoir des architectures suffisamment flexibles pour adapter les différentes charges de travail aux niveaux appropriés, le tout au sein d'un environnement sécurisé et conforme, que les administrateurs cloud peuvent gérer efficacement.

La vraie question n'a jamais été « public ou privé ? »

La vraie question est : « Comment pouvons-nous offrir aux équipes de test la couverture dont elles ont besoin sans exposer nos données ni dépasser notre budget ? »

Voilà ce que signifie « Partagé, pas exposé ». Et c’est l’avenir que nous construisons.