Passez en revue votre propre compte section par section. Notez les parties du profil que vous avez rendues privées, puis vérifiez séparément votre statut saisi par vous-même et tout ce que vous avez publié auparavant : rendre un profil privé masque des sections du profil, mais un statut peut rester public et les ressources auparavant publiques ne sont pas rappelées. Retirez les formulations sensibles de votre propre statut et consignez les anciens travaux publics comme un historique que vous ne pouvez pas dépublier avec un simple réglage de confidentialité. C'est une habitude d'inventaire, pas un interrupteur qui efface le passé.
Trouvez des indices sur les profils sociaux publics avec notre application TraceSeek.
Commencez par deux listes distinctes
Traitez cela comme deux inventaires, et non comme un seul réglage de confidentialité. Sur la première liste, notez les sections du profil que vous contrôlez sur votre propre compte et si chacune est privée ou visible. Sur la seconde liste, notez ce qui se situe en dehors de ces sections : votre texte de statut saisi par vous-même et toute ressource qui était publique auparavant. Rendre un profil privé masque des sections du profil, mais cela ne masque pas toutes les ressources auparavant publiques, et un statut saisi par vous-même peut rester public. Gardez les deux listes séparées pour ne pas confondre un profil privé avec une table rase. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
- Listez les sections du profil que vous avez définies comme privées.
- Listez séparément votre texte de statut et toute ressource auparavant publique.
- Marquez chaque élément comme contrôlé par le propriétaire, public par conception, ou historique auparavant public.
Examinez le champ de statut comme un texte que vous avez écrit vous-même
Votre statut est quelque chose que vous avez écrit, il relève donc de votre propre nettoyage, et non d'une affirmation sur ce que masque une plateforme. Ouvrez votre profil en étant connecté et lisez la ligne de statut comme le ferait un inconnu. Retirez les détails que vous avez écrits vous-même et que vous ne voulez plus voir visibles. Considérez la modification du texte lui-même comme l'étape de protection, car les faits vérifiés établissent seulement qu'un statut peut rester public même lorsque les sections du profil sont privées ; décider quels détails sont sensibles relève de votre jugement. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
- Réécrivez ou effacez le texte de statut que vous ne voulez plus voir visible.
- Relisez la nouvelle formulation comme si vous étiez un inconnu.
- Notez la date à laquelle vous l'avez modifié.
Les anciens travaux publics sont de l'historique, pas un réglage
Les ressources qui étaient publiques auparavant ne sont pas rappelées par le fait de rendre le profil privé. L'historique des commits, les anciens projets publics et tout ce qui a déjà été copié ou indexé peuvent survivre à un changement de visibilité. N'affirmez pas qu'un réglage de confidentialité efface l'historique du projet ; consignez plutôt les anciens éléments publics sur votre inventaire et décidez élément par élément si cette exposition compte encore pour vous. Là où vous ne pouvez pas modifier quelque chose, écrivez indisponible et arrêtez-vous à cette limite plutôt que de deviner. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
- Consignez les anciens projets et commits publics comme historique sur votre liste.
- Décidez si chacun compte encore ; là où vous ne pouvez pas agir, écrivez indisponible.
- Ne décrivez pas un changement de confidentialité comme effaçant l'historique du projet.
Séparez les champs e-mail et identité
L'e-mail de votre profil et votre e-mail de commit sont des réglages différents, et un e-mail de commit privé généré automatiquement est disponible pour les travaux futurs. Cela n'efface pas rétroactivement les anciens commits publics, alors vérifiez les deux surfaces sur votre propre compte. Le même soin s'applique aux champs de comptes sociaux externes, qui peuvent contenir des identifiants tels qu'un ID utilisateur Discord ou un nom d'utilisateur GitHub plutôt qu'un nom d'affichage. Examinez ces champs comme des identifiants que vous avez choisi de publier. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
- Comparez les réglages d'e-mail du profil et d'e-mail de commit.
- Notez les anciens commits qui portent encore l'adresse précédente.
- Lisez les champs de comptes externes comme des identifiants, pas des noms d'affichage.
Contributions et présence ne sont pas des preuves
Les propriétaires peuvent afficher des actions de contribution privées sans publier toutes les informations du projet sous-jacent. Lisez un graphique de contributions comme un résumé de l'activité, et non comme une présence en temps réel ni un registre d'identité. Cela compte lorsque vous auditez votre propre empreinte : un graphique silencieux ou une section privée ne prouve pas qu'une personne est absente, et un graphique visible ne prouve pas une activité actuelle. Gardez les observations, leurs limites et vos décisions dans des colonnes séparées pour que l'audit reste honnête. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
Un inventaire concret (hypothétique)
Supposons qu'un propriétaire ait masqué plusieurs sections du profil mais laissé un statut mentionnant une ville et une routine hebdomadaire. Leur ancien projet public montre encore des commits anciens sous une adresse qu'ils n'utilisent plus. Notez que GitLab.com et les instances hébergées de manière indépendante sont des contextes de compte distincts, alors confirmez quel hôte vous examinez. La feuille de calcul hypothétique ci-dessous place chaque observation à côté de sa limite et de la prochaine étape pratique. [GitLab Docs : profil public, ID de compte et paramètres du propriétaire]
| observation | limite | étape suivante |
|---|---|---|
| Sections du profil définies comme privées | Ne masque pas les ressources auparavant publiques | Listez les anciens projets publics comme historique, pas comme réglé |
| Le statut mentionne une ville et une routine hebdomadaire | Le statut peut rester public malgré des sections privées | Réduisez le texte de statut à une formulation neutre |
| Les anciens commits utilisent un e-mail antérieur | L'e-mail de commit privé ne s'applique qu'à l'avenir | Consignez les anciens commits comme historique ; décidez si une action est possible |
Encore quelques questions
Rendre mon profil GitLab privé masque-t-il mon statut et mes anciens projets ?
Non. Un profil privé masque des sections du profil, mais un statut saisi par vous-même peut rester public et les ressources auparavant publiques ne sont pas rappelées. Modifiez vous-même le texte de statut et consignez les anciens travaux publics comme historique.
Puis-je effacer d'anciens commits publics avec un e-mail de commit privé ?
Non. Un e-mail de commit privé généré automatiquement est disponible pour les travaux futurs, mais il n'efface pas rétroactivement les anciens commits publics. Listez-les comme historique et décidez élément par élément.
Que faire si je ne peux pas modifier quelque chose que je trouve ?
Consignez-le comme indisponible et arrêtez-vous à la limite d'accès. Utilisez l'aide officielle actuelle de la plateforme pour cette surface, ou demandez à un co-mainteneur que vous connaissez déjà un lien sur base volontaire, sans considérer le silence comme une preuve de quoi que ce soit.
Sources et notes éditoriales
Références officielles vérifiées le 23 octobre 2026. Les listes de contrôle, tableaux comparatifs et exemples de formulation sont des outils éditoriaux de DateClues, et non des tests officiels ou des scores de risque validés.
Informations générales. Aucun guide ou outil ne peut certifier l'identité, les intentions ou la sécurité d'une personne. Lire nos normes éditoriales.