OnceMac attribue à chaque commande un nœud Mac mini physique dédié. Le calcul, la mémoire et le stockage local ne sont pas partagés avec d’autres clients, avec un objectif de disponibilité de 99,9 %.
Dédié signifie que les ressources physiques ne sont pas mélangées avec celles d’autres clients, et non qu’un quota virtuel est découpé sur un hôte partagé.
Après confirmation de la commande, la console enregistre la configuration, le nœud et la durée, puis attribue le Mac mini correspondant. Pendant cette période, l’appareil n’est pas utilisé simultanément par un autre client.
Le CPU, la mémoire unifiée et le SSD de base appartiennent à ce nœud physique. Les files de build ne sont pas mises en concurrence par la charge soudaine d’un autre locataire, ce qui convient aux chaînes d’outils fixes et aux tâches continues.
Vous pouvez configurer l’interface graphique macOS et l’environnement en ligne de commande, tout en restant responsable des comptes système, clés SSH, licences logicielles, éléments de signature et données métier.
Les états sont agrégés par jour calendaire. L’évaluation s’appuie sur la supervision de la plateforme, les journaux de connexion et les preuves des tickets ; les erreurs de configuration du client ne sont pas comptées dans la disponibilité de la plateforme.
Nous observons l’état des nœuds physiques, l’accessibilité des liaisons de gestion et les services essentiels de la plateforme. Un arrêt volontaire, un problème de réseau local, une règle de pare-feu erronée ou une charge client ne constituent pas un incident de plateforme.
Si la responsabilité de la plateforme est confirmée et que l’engagement applicable à la commande n’est pas atteint, OnceMac accordera un crédit de service selon les conditions, le périmètre de calcul et la procédure de demande prévus dans les conditions de service.
Vérifier les règles applicablesLes clés, le principe du moindre privilège et les accès révocables doivent être appliqués ensemble. Une seule mesure laisse encore des identifiants persistants ou des comptes partagés exposés.
Créez un compte personnel et une clé distincte, accordez uniquement les droits nécessaires aux répertoires, dépôts et builds, puis consignez la personne ayant autorisé l’accès.
Révoquez le compte système, la clé publique SSH, les jetons de dépôt et les clés d’automatisation ; vérifiez les tâches en cours et remplacez les identifiants autrefois partagés.
La console de gestion, les connexions distantes et le trafic métier relèvent de responsabilités différentes. En cas d’anomalie, identifiez d’abord la couche concernée pour accélérer le diagnostic.
| Périmètre | Responsabilité de OnceMac | Responsabilité du client | Vérification recommandée |
|---|---|---|---|
| Accès à la console de gestion | Accès au compte, commandes, état du nœud et canal de tickets | Protection des identifiants, autorisations des membres et vérification des connexions anormales | Journaux de connexion, liste des membres, opérations récentes |
| SSH et connexion graphique | Accessibilité du réseau de base et conditions de connexion du nœud | Droits des clés, comptes système, pare-feu et restrictions de source | Réseau local, ports, droits des clés, adresses sources |
| Builds et trafic métier | Réseau de base du nœud physique et observation des liaisons amont | Proxy, sources de dépendances, accès aux dépôts, écoute de l’application et règles de trafic | DNS, routage, configuration du proxy, réponse du service cible |
| Diagnostic des accès anormaux | Croisement des journaux de plateforme pour confirmer les anomalies du nœud et de la gestion | Examen des journaux système, clés autorisées, processus et changements de tâches | Source, période, compte, commande et journaux désensibilisés |
Vérifiez d’abord le réseau local, puis l’état du nœud dans la console, les droits des clés SSH et le pare-feu système ; joignez enfin la période et une sortie désensibilisée au ticket.
Les règles s’appliquent selon le cycle de vie du nœud. Si votre projet exige une certification, un rapport d’audit ou une norme contractuelle de traitement des supports, confirmez le périmètre applicable auprès du support avant la commande.
Vérifiez l’appareil et la configuration de la commande, préparez le système de base et la connectivité, puis consignez l’attribution du nœud. Le client reçoit un nœud physique dédié, pas un quota de ressources partagé.
Le client gère les répertoires de travail, identifiants de dépôt, caches de build, éléments de signature et données métier. Chiffrez les informations sensibles et évitez de les inscrire dans des scripts, journaux ou historiques de commandes conservés durablement.
Exportez d’abord les artefacts et journaux nécessaires, vérifiez la restauration des sauvegardes métier, puis révoquez les jetons de dépôt, clés publiques SSH et identifiants d’automatisation. Ne considérez pas le disque local du nœud comme votre seule copie.
Le nœud n’est attribué à une commande ultérieure qu’après son processus de préparation. Toute exigence dépassant le service standard doit être convenue par écrit avant confirmation de la commande, sans remplacer le processus réel par une certification non confirmée.
La supervision vérifie l’état des services de base sans lire le contenu du code client. Si les données du client sont nécessaires au diagnostic, nous ne recueillons que les informations indispensables et désensibilisées.
Vérifier que le nœud est en ligne, que les fonctions essentielles de gestion répondent et que l’état matériel ne nécessite pas d’examen complémentaire.
Contrôler la liaison de gestion, le réseau de base du nœud et les connexions amont afin de distinguer un problème réseau de plateforme d’une anomalie du service cible du client.
Surveiller les indicateurs de capacité nécessaires du nœud et de la plateforme ; le client doit définir lui-même les seuils de ses répertoires de travail et caches de build.
Consigner les changements touchant la livraison du nœud, l’accès de gestion ou le chemin réseau afin de pouvoir les relier à la chronologie d’un incident.
Chaque étape produit un résultat clair, afin d’éviter de modifier à répétition l’environnement client sans cause confirmée.
Vérifiez le nœud, la commande, l’heure de début, l’accès touché et les conditions de reproduction pour déterminer s’il s’agit d’un problème de nœud, de liaison ou de plateforme.
Limitez la propagation de l’impact, conservez les preuves nécessaires et évitez toute action non confirmée susceptible d’écraser les journaux d’origine.
Rétablissez d’abord le chemin fonctionnel, puis vérifiez la connexion, le build et les tâches essentielles. Si la configuration client est concernée, précisez d’abord le périmètre de l’intervention.
Reconstituez la chronologie, la cause, l’impact et les actions suivantes ; si l’intervention du client est nécessaire, fournissez des recommandations concrètes de configuration ou de sauvegarde.
Les six nœuds OnceMac fonctionnent 365 jours par an. Les opérations courantes assurent une continuité de fonctionnement toute l’année, et les incidents imprévus donnent priorité au rétablissement du service et à la réduction de l’impact.
L’objectif de fiabilité ne remplace pas les sauvegardes métier. Conservez au minimum les quatre types de copies hors nœud suivants :
Si un incident affecte une commande existante, ouvrez un ticket dans la console avec le numéro de commande, le nœud, la période, les étapes de reproduction et les journaux désensibilisés.
Ouvrir un ticket dans la consoleEnvoyez la configuration, le nœud, les types de données, les exigences d’audit et la date souhaitée d’activation à support@oncemac.com. L’équipe répondra selon le périmètre réel du service ; les conditions techniques ne sont pas remplacées par une certification non confirmée.
Choisissez le Mac mini adapté parmi trois configurations disponibles et déterminez votre point de connexion parmi six nœuds. Toutes les commandes sont facturées en dollars américains.