Adresse e-mail du support
Pour le choix avant-vente, les achats d’équipe, les questions de facturation et les partenariats. Précisez l’usage, le volume, la durée et la réponse attendue.
support@pingmini.comLes demandes de choix avant-vente, de support technique, d’achat d’équipe, de facturation et de partenariat suivent des circuits différents. Vous pouvez écrire à support@pingmini.com ; si vous avez déjà une commande ou utilisez déjà le service, connectez-vous à la console et ouvrez un ticket afin de faciliter l’association avec l’instance et l’historique de traitement.
Classez d’abord votre demande, puis joignez les informations permettant de la vérifier.
Pour le choix avant-vente, les achats d’équipe, les questions de facturation et les partenariats. Précisez l’usage, le volume, la durée et la réponse attendue.
support@pingmini.comPour les interruptions de connexion, échecs de build, anomalies de performances, statuts de commande ou problèmes liés à un service en cours. Le ticket peut être directement associé à la commande et à l’instance.
Se connecter à la console et ouvrir un ticketÉcrire simplement « ça ne fonctionne pas » ou « nous voulons acheter » ne suffit généralement pas pour commencer l’analyse. Les catégories ci-dessous indiquent les informations les plus utiles et le canal à privilégier.
Indiquez le projet Xcode, les tâches d’automatisation, les tests de modèles ou les opérations de transcodage prévus, leur durée d’utilisation et si vous avez besoin d’un SSD supplémentaire ou d’une connexion Thunderbolt 5 en parallèle.
Indiquez le numéro de commande, le nœud, l’heure de l’incident, le message d’erreur exact, les étapes de reproduction et les vérifications déjà effectuées. Pour un problème sur un service en cours, privilégiez le ticket dans la console.
Indiquez le nombre de tâches exécutées simultanément, les rôles des membres, la durée d’utilisation, le mode de transmission du projet et si les répertoires de travail doivent être séparés par nœud ou par projet.
Indiquez le numéro de commande, le type de paiement, les éléments de facture à vérifier et l’état actuel de la page. N’envoyez jamais de justificatif de paiement complet ni d’informations d’authentification sensibles dans l’e-mail.
Décrivez le flux de développement concerné, les résultats attendus, les équipes participantes, le calendrier et les limites techniques à valider avec PingMini. Nous vérifierons d’abord que les conditions d’exécution sont clairement définies, puis poursuivrons les échanges par e-mail.
Le formulaire utilise votre client e-mail pour créer le message et n’envoie pas son contenu à un autre service de formulaire en ligne. Vous pouvez encore le vérifier et le modifier avant l’envoi.
Au lieu d’écrire « j’ai besoin de hautes performances », précisez la taille du projet, la fréquence des builds, le nombre de tâches simultanées, la taille des modèles, la résolution des ressources et le volume de données à conserver.
PingMini propose trois configurations fixes et cinq nœuds. Si les limites de la charge sont claires, passez directement à la configuration ; la console indique la disponibilité réelle en temps réel.
Si vous utilisez déjà le service, ouvrez de préférence un ticket dans la console afin d’associer la commande et l’instance. Si vous devez écrire par e-mail, fournissez au moins les champs suivants, sans envoyer de mot de passe, de clé privée ni d’identifiants complets.
Le ticket conserve l’état du problème, les informations complémentaires et le contexte des actions suivantes ; il facilite aussi l’identification de la commande et du nœud physique concernés.
Vérifiez si la même action peut être reproduite de manière fiable et distinguez les limites entre réseau local, session distante, chaîne d’outils macOS, dépendances du projet et scripts d’automatisation.
Pour les équipes CI/CD et les groupes de développement, la question clé n’est généralement pas la configuration d’une seule machine, mais la file d’attente des tâches, l’isolation des projets, le relais entre membres et les artefacts à conserver pendant la durée de location.
Indiquez le nombre de builds, tests, archivages ou tâches d’inférence exécutés simultanément au pic, en précisant ceux qui doivent disposer d’un répertoire de travail exclusif.
Expliquez comment les membres du développement, des tests, de la publication et des opérations se relaient, si les répertoires doivent être séparés par projet et qui migre les données avant la fin de la location.
Distinguez un pic de publication ponctuel, un cycle d’itération régulier et des builds continus à long terme. Indiquez la date de démarrage prévue, les conditions de fin et les éventuels besoins d’extension par phase.
L’ordre de traitement dépend de l’impact sur un service en cours, de l’exhaustivité des informations et de la possibilité d’associer une commande ou de reproduire le problème. Nous ne promettons pas de délai fixe impossible à vérifier.
Ouvrez un ticket dans la console avec le numéro de commande, le nœud, l’heure, le message d’erreur et les étapes de reproduction. Les problèmes sur un service en cours avec des informations complètes passent en priorité au contrôle technique.
Pour une commande existante, privilégiez le ticket dans la console en indiquant les éléments à vérifier et l’état actuel de la page. Si la console est momentanément inaccessible, envoyez le contexte nécessaire depuis l’adresse e-mail du support.
Les demandes courantes passent par l’adresse e-mail du support. Nous vérifions d’abord si les informations suffisent ; s’il manque le volume de tâches, le nœud, la durée ou le résultat attendu, nous demanderons des précisions.
Ajoutez les nouveaux éléments dans le même fil d’e-mail ou ticket, en conservant la commande, le nœud et le contexte d’erreur. Évitez de créer plusieurs demandes non reliées pour un même problème.
Une demande avant-vente doit aboutir à une recommandation de configuration ou de durée ; une demande technique doit aboutir aux prochaines vérifications, aux éléments à fournir ou à un état de traitement clair.
L’adresse e-mail, les informations liées à la commande, le nœud, les journaux d’erreur et les étapes de reproduction servent uniquement à répondre à la demande, fournir le service et diagnostiquer le problème. Supprimez les données de projet sans rapport avec l’incident et masquez les mots de passe, clés privées, jetons et éléments d’authentification complets.
Les trois configurations fixes couvrent le développement quotidien, les builds continus et l’inférence de grands modèles. Pour un problème sur un service existant, utilisez un ticket dans la console ; pour l’avant-vente et les partenariats, envoyez un e-mail structuré.