Accès trop large : ne communiquez ni votre compte principal ni vos clés privées ; créez une identité distincte, limitez chaque droit à la tâche et prévoyez son retrait.
Si la séparation des identifiants de publication n’est pas vérifiable, gardez la signature et l’envoi de l’application sous votre responsabilité.

Ce guide s’adresse aux indépendants qui délèguent une correction, une construction ou des tests iOS sans céder leurs identifiants Apple.
Il concerne aussi les responsables de petites équipes qui ouvrent un Mac distant, un dépôt de code ou App Store Connect à un prestataire.
Les responsables techniques y trouveront une méthode pour convenir des tâches, des livrables et de la reprise en main.

Avant l’ouverture : définir les frontières du mandat

Dans une collaboration iOS, « donner accès au Mac » peut recouvrir plusieurs autorisations qui ne se confondent pas : ouvrir une session macOS, lire ou modifier un dépôt, consulter les ressources de l’équipe Apple, gérer une application dans App Store Connect, ou utiliser des éléments de signature. Accordez chaque accès séparément. N’inférez pas qu’un droit donne automatiquement les autres, ni qu’il les exclut.

Commencez par décrire ce que le prestataire doit effectivement livrer : modification du code, exécution d’un test, archive de développement, remise d’un fichier compilé ou téléversement pour publication. Pour chaque livrable, notez la ressource nécessaire, la personne qui autorise, les éléments qui serviront à contrôler l’accès et la condition de fin. Une mission de correction peut ne nécessiter qu’un dépôt de projet et un environnement de construction. Une mission de publication peut impliquer des accès Apple supplémentaires, à examiner indépendamment.

Le prestataire doit-il recevoir un compte Apple Developer ?

Pas systématiquement. Si sa tâche se limite à modifier le code et à produire un résultat de développement sans accéder aux ressources de l’équipe Apple, ne lui transmettez pas le compte du propriétaire. S’il doit intervenir sur une application, un service ou une ressource d’équipe, évaluez l’invitation nominative et le rôle correspondant au travail attendu.

Apple distingue les comptes individuels et les équipes d’organisation : l’accès d’un utilisateur App Store Connect ajouté par un titulaire individuel ne correspond pas aux accès d’un membre d’une organisation. Vérifiez les droits applicables au type de compte concerné dans la présentation Apple des comptes et des rôles. Les intitulés et capacités des rôles doivent être contrôlés dans la documentation officielle des rôles de développeur, au moment où vous préparez l’invitation.

Pour une mission iOS en sous-traitance, consignez aussi ce qui reste interdit : consulter d’autres applications, gérer les utilisateurs, modifier des paramètres d’équipe ou agir sur la publication si ce n’est pas prévu au contrat. La liste des droits doit correspondre à la mission, pas à la commodité de la personne qui configure les accès.

Répartition des accès avant le démarrage

  • Code source : désignez le dépôt et les dossiers concernés ; donnez le niveau de lecture ou de modification nécessaire, sans ouvrir par défaut les autres projets.
  • Mac distant : prévoyez une identité nominative et une procédure de connexion propre au prestataire. Vérifiez auprès de votre fournisseur quelles restrictions s’appliquent réellement aux comptes locaux et aux sessions distantes.
  • Ressources Apple : n’invitez le prestataire que si ses tâches l’exigent ; sélectionnez le rôle et les applications accessibles après vérification des droits.
  • Signature et publication : identifiez la personne qui conserve les certificats, les clés privées et les identifiants de téléversement.
  • Fin de mission : nommez la personne qui retirera chaque accès et celle qui contrôlera que les anciens moyens de connexion ne fonctionnent plus.

L’accès au compte Apple du propriétaire n’est pas une solution de partage. Apple recommande de protéger la connexion au compte et décrit les mesures associées dans ses instructions de connexion et de sécurité. Gardez donc les identifiants du titulaire pour vous. N’envoyez pas de mot de passe, de clé privée ou de jeton complet dans une conversation, un ticket ou un dépôt.

Première connexion : créer une identité vérifiable

Une identité individuelle vous permet de savoir qui a ouvert une session et facilite la révocation ciblée. Ne prêtez pas votre utilisateur macOS personnel, votre compte propriétaire Apple ou un compte partagé entre prestataires. Demandez à chaque intervenant d’utiliser une identité identifiable et conservez la trace de son autorisation, des ressources accessibles et de la date ou de la condition de retrait convenue.

Peut-on créer un compte distinct sur le Mac distant ?

Oui, si l’environnement le permet et si cette option a été vérifiée auprès de l’opérateur. Mais un compte macOS séparé ne prouve pas, à lui seul, que tous les secrets, fichiers partagés, volumes ou éléments de signature sont isolés. Vous devez contrôler le fonctionnement réel de la machine et les accès configurés autour de la session. N’annoncez pas au prestataire une séparation que vous n’avez pas pu vérifier.

Pour l’accès à distance, choisissez les moyens de connexion adaptés au travail prévu et définissez qui peut les activer ou les désactiver. Selon l’environnement, il peut s’agir d’une session graphique ou d’un accès en ligne de commande ; leur présence ne doit pas être interprétée comme une permission générale sur les dépôts ou sur les comptes Apple. Gardez une procédure de coupure accessible au responsable du projet, y compris si le prestataire change d’appareil ou cesse de répondre.

Côté dépôt, créez une autorisation nominative plutôt que de partager un identifiant d’équipe. La documentation GitHub distingue les rôles d’accès à un dépôt d’organisation et décrit la gestion de l’accès d’un individu dans la documentation des rôles de dépôt. Appliquez le même principe à tout autre dépôt : attribuez le niveau nécessaire, puis vérifiez la liste des collaborateurs après la création de l’accès.

Une connexion réussie ne valide pas la sécurité du partage. Elle prouve seulement que la personne peut se connecter ; elle ne démontre ni qu’elle ne voit que le projet prévu, ni qu’elle ne dispose pas d’un droit de publication.

Dans votre journal de passation, inscrivez l’identité créée, la personne qui a autorisé l’accès, les ressources accordées, le canal de connexion et la condition de fin. Le prestataire doit pouvoir confirmer le périmètre sans vous demander un mot de passe ou un secret privé. Si une autorisation a été accordée à l’oral, formalisez-la avant de poursuivre.

Première construction : vérifier les droits en situation réelle

Faites valider les autorisations avec une tâche de faible risque, sur le projet convenu. Le prestataire doit pouvoir récupérer le code concerné, lancer la construction ou les tests demandés, puis remettre un résultat à l’emplacement prévu. Pendant ce contrôle, examinez également les ressources auxquelles il ne devrait pas avoir accès. Une construction réussie ne suffit pas si elle a été obtenue au moyen de droits plus larges que le mandat.

Cette étape est aussi le moment de dissocier trois questions : l’accès au dépôt, la connexion à la machine et les permissions accordées par Apple. Par exemple, donner accès à un dépôt ne crée pas une permission App Store Connect ; inversement, une invitation App Store Connect ne prouve pas que le prestataire possède un compte macOS ou un accès au code.

Matrice d’autorisation à remplir

Pour chaque ligne, notez l’identité autorisée et faites confirmer l’accès par un contrôle concret. Laissez « non accordé » lorsque la tâche n’en a pas besoin.

Ressource Autorisation prévue Responsable Preuve de contrôle Condition de retrait
Session macOS distante Connexion au compte nominatif et au projet prévu À renseigner Liste des comptes et essai de connexion Fin de mission ou changement d’intervenant
Dépôt de code Lecture ou modification du dépôt désigné À renseigner Liste des collaborateurs et vérification de l’accès Livraison acceptée
App Store Connect Rôle requis et périmètre d’applications contrôlé À renseigner Rôle et applications accessibles vérifiés Retrait après la tâche autorisée
Ressources de l’équipe Apple Accès uniquement si le travail le nécessite À renseigner Droits comparés à la tâche confiée Fin de la mission concernée
Signature et API Aucun accès par défaut ; exception justifiée et révocable À renseigner Responsable des secrets et méthode de révocation Retrait selon le plan de publication

App Store Connect permet de gérer l’accès aux applications. Vérifiez les applications effectivement accessibles, pas seulement le rôle affiché, en suivant les instructions Apple pour modifier l’accès aux apps. Ce contrôle évite de confondre l’existence d’un compte utilisateur avec un accès limité au seul projet externalisé.

Pour la construction, demandez un résultat reproductible et lisible par l’équipe : branche ou révision utilisée, étapes effectuées, erreurs rencontrées et emplacement du livrable. Les captures d’écran et journaux doivent masquer les noms de comptes, adresses de machine, identifiants de dépôt, identifiants d’équipe et valeurs de configuration sensibles. Les exemples de commande doivent remplacer ces éléments par des marqueurs explicites, jamais par de vraies données.

Livraison : garder la maîtrise de la signature et de la publication

Séparez le travail sur le code de la décision de signer et de publier. Le sous-traitant peut être chargé d’une modification ou d’une construction de développement sans recevoir les moyens d’émettre une version destinée à la distribution. Si votre processus ne permet pas d’isoler les secrets de publication ou d’en limiter l’usage, réalisez vous-même la signature et l’envoi officiel.

Ne traitez pas un certificat, une clé privée ou une clé API comme un fichier de projet ordinaire. Convenez de ce qui peut être remis : sources modifiées, rapport de test, archive non signée, ou autre livrable approuvé. Si le prestataire doit participer à la publication, documentez précisément le besoin, les limites du droit, la personne responsable et la marche à suivre si l’accès doit être interrompu.

Apple documente la création des clés d’API App Store Connect et leurs autorisations dans son guide sur la création de clés pour l’API App Store Connect. Avant d’en créer ou d’en confier une, vérifiez le type de clé, son périmètre et le processus de gestion associé. La documentation Apple précise également les différences de portée entre clés d’équipe et clés individuelles ainsi que la gestion des clés dans son guide sur l’API App Store Connect. Suivez la procédure officielle en vigueur : une clé révoquée ne peut pas être restaurée, ce qui rend le choix du moment et l’évaluation des dépendances importants.

Si vous ne pouvez pas confirmer qui a utilisé un secret, ou si une clé a été déposée dans un endroit partagé, ne la révoquez pas à l’aveugle pendant une publication en cours. Isolez d’abord l’accès concerné, identifiez les usages qui en dépendent et évaluez l’effet d’un remplacement. Ensuite, suivez le processus Apple et consignez la révocation ou le remplacement. Le but est de réduire l’exposition sans casser le processus de livraison par une intervention non préparée.

Pour éviter un blocage au départ du prestataire, conservez côté projet les instructions nécessaires pour reprendre la construction et la publication. Le dépôt, les décisions de configuration, l’emplacement des livrables et le responsable des secrets doivent rester compréhensibles par l’équipe. Ne demandez jamais au prestataire de vous envoyer ses propres secrets privés pour compenser un manque de procédure.

Fin de mission : retirer chaque accès et contrôler la reprise

La fin de la tâche déclenche un contrôle distinct pour chaque ressource. Supprimer un compte de la machine ne retire pas nécessairement son accès au dépôt, à App Store Connect ou à une clé API. De même, retirer une personne du dépôt ne désactive pas une méthode de connexion distante. Faites l’inventaire à partir de la matrice, puis demandez au responsable de chaque service de confirmer le retrait.

  • Machine : désactivez le compte ou la méthode de connexion du prestataire selon la configuration réellement utilisée ; vérifiez la liste des comptes et les moyens d’accès encore actifs.
  • Code : retirez le collaborateur du dépôt concerné et contrôlez de nouveau la liste des personnes autorisées, conformément aux procédures du service utilisé.
  • App Store Connect : supprimez l’accès de l’utilisateur si la mission est terminée et contrôlez ses droits et son périmètre d’applications.
  • Équipe Apple : vérifiez séparément les accès aux ressources d’équipe ; ne déduisez pas leur état de la suppression d’un autre compte.
  • API et secrets de projet : identifiez les clés ou valeurs auxquelles le prestataire a pu accéder ; révoquez ou remplacez celles dont l’exposition ou l’usage ne peut pas être écarté.
  • Livrables : confirmez que le code, les rapports et les éléments convenus sont remis à l’équipe et que la personne responsable peut reprendre la suite.

La validation doit être menée depuis un compte de projet autorisé, pas uniquement à partir de la déclaration du prestataire. Contrôlez les listes de membres et les méthodes d’accès encore utilisables. Si l’état d’une permission reste incertain, notez l’incertitude, identifiez le propriétaire de l’action et bloquez les opérations sensibles jusqu’à résolution.

Une passation complète comprend aussi un bref compte rendu : travail livré, révision du code concernée, emplacement des résultats, accès retirés, secrets examinés et points restant à traiter. Si un élément n’a pas été retiré ou ne peut pas être vérifié, il ne faut pas le déclarer clos. Transmettez l’action à une personne nommée et conservez la trace de sa vérification.

Répétition avant le vrai mandat : tester le parcours complet

Avant le démarrage officiel, simulez la collaboration avec un projet sans enjeu de publication. Demandez au prestataire d’utiliser son identité nominative, de se connecter au Mac distant, d’accéder au dépôt désigné, d’exécuter le travail convenu et de remettre un livrable. Faites ensuite retirer ses accès et vérifiez depuis le compte du projet qu’ils ne sont plus utilisables.

Cette répétition sert à repérer les erreurs de procédure avant qu’elles ne touchent une version destinée aux utilisateurs : accès accordé au mauvais dépôt, rôle Apple trop large, secret copié dans un journal, ou impossibilité de désactiver rapidement une session. Elle confirme également que l’équipe peut reprendre le travail sans dépendre du compte personnel ou de l’environnement privé du prestataire.

  • [ ] Chaque intervenant possède une identité distincte ; aucun compte propriétaire n’est partagé.
  • [ ] Le mandat indique les projets, tâches, ressources et livrables autorisés.
  • [ ] L’accès au Mac, au dépôt, aux ressources Apple et à App Store Connect a été vérifié séparément.
  • [ ] Le rôle et le périmètre des applications App Store Connect correspondent à la tâche confiée.
  • [ ] Les clés privées, certificats et clés API ne sont pas transmis comme des fichiers de projet.
  • [ ] Le responsable de la signature et de l’envoi officiel est identifié.
  • [ ] La personne chargée de retirer chaque accès est nommée.
  • [ ] Le retrait a été vérifié sur la machine, dans le dépôt et dans les services Apple concernés.
  • [ ] Les livrables et les consignes de reprise sont disponibles pour l’équipe.

Si votre configuration actuelle repose sur un Mac personnel, des comptes partagés ou une machine dont l’accès n’est pas facile à couper, elle peut exposer des données privées, rendre les responsabilités floues et compliquer le départ du prestataire. Un environnement Mac distinct peut mieux convenir à une mission temporaire, à condition de vérifier avant l’ouverture les comptes réellement disponibles, les modalités de connexion et le processus de révocation. La location ne remplace pas votre contrôle des rôles Apple ni la protection des secrets ; elle peut toutefois éviter de transformer votre poste de travail quotidien en machine partagée. Si vous avez besoin d’un environnement macOS pour une collaboration ponctuelle, consultez les options de Mac distant proposées par MACCOME, puis confirmez les conditions d’accès et de passation avant d’y confier un projet. Vous pouvez aussi parcourir l’offre MACCOME en français pour évaluer si cette solution correspond à votre organisation.