Tech

Sécuriser ses comptes dev : la base qu'on repousse trop souvent

GitHub, email, SSH, MFA... Sécuriser ses comptes dev n'est pas un bonus de perfectionnisme. C'est une fondation. Voici pourquoi et par où commencer.

Quand on commence à coder sérieusement, on pense souvent au portfolio, aux projets, à GitHub, au déploiement, au design, au SEO, à la visibilité. On veut publier, apprendre vite, montrer qu'on progresse. C'est normal.

Mais il y a un sujet que beaucoup de développeurs, surtout au début, traitent trop tard : la sécurité de leurs comptes.

Un compte GitHub, un accès à un hébergeur, une boîte mail, un nom de domaine, un compte Vercel, Netlify, Google, Notion, Stripe ou même un simple terminal mal protégé — ce n'est pas "juste un compte". C'est déjà une partie de ton activité, de ton identité numérique et parfois de tes revenus futurs.

Sécuriser ses comptes dev ne relève plus du bonus ou du perfectionnisme. C'est une base. Pas parce qu'il faut devenir parano. Mais parce qu'il faut être lucide.

Le vrai problème : on croit qu'on sécurisera "plus tard"

Le piège classique, c'est celui-ci :

"Je suis débutante, je n'ai rien d'important." "Mon projet n'est pas encore en production." "Je ferai ça quand mon business grandira."

C'est précisément au début qu'il faut poser des fondations propres.

Parce qu'un compte compromis, ce n'est pas seulement une question technique. C'est aussi :

  • du temps perdu,
  • de la crédibilité abîmée,
  • des déploiements cassés,
  • un domaine ou un repo qu'on ne contrôle plus,
  • des emails pro qui partent dans de mauvaises mains,
  • et parfois une vraie perte financière.

Quand on construit en public, qu'on publie sur GitHub, qu'on relie plusieurs outils entre eux, la surface d'exposition augmente très vite. On ouvre un compte ici, on connecte un service là, on autorise une intégration, on colle une clé API, on se connecte depuis plusieurs appareils — et si on n'a pas de discipline, on empile de la fragilité.

Tous tes comptes n'ont pas la même valeur, mais certains sont critiques

La première erreur, c'est de mettre tous ses comptes dans la même catégorie mentale.

Non, ton compte GitHub, ton email principal et ton registrar de domaine n'ont pas la même importance qu'un compte secondaire ouvert pour tester un outil. Certains comptes sont stratégiques, parce qu'ils permettent d'accéder aux autres.

Je les appelle les comptes-pivots.

Dans la pratique, il faut traiter comme ultra sensibles :

  • ton adresse email principale,
  • ton compte GitHub,
  • ton gestionnaire de mots de passe,
  • tes comptes de déploiement et d'hébergement,
  • ton nom de domaine,
  • tes outils d'administration ou de paiement,
  • tes comptes cloud ou consoles techniques.

Pourquoi ? Parce que si un attaquant récupère l'un de ces accès, il peut souvent réinitialiser ou compromettre le reste.

L'email, surtout, est un point central. Si quelqu'un entre dans ta boîte mail principale, il peut lancer des réinitialisations de mot de passe partout. À partir de là, ton problème n'est plus un seul compte compromis. C'est toute ta chaîne de confiance qui devient instable.

Le mot de passe seul ne suffit plus

Il faut le dire clairement : un bon mot de passe, seul, n'est plus une stratégie suffisante.

Oui, il faut des mots de passe longs, uniques, aléatoires, différents pour chaque service. Ça, c'est la base. Mais ce n'est pas la fin du sujet.

Le vrai changement de niveau, c'est l'association de trois choses :

  1. un mot de passe unique et solide,
  2. un gestionnaire de mots de passe,
  3. une authentification à deux facteurs (2FA) ou multi-facteurs (MFA).

Sans gestionnaire, on retombe vite dans les travers habituels : variations du même mot de passe, notes éparpillées, habitudes fragiles, mémoire approximative. Et sans MFA, un mot de passe volé ou réutilisé ailleurs peut suffire à ouvrir la porte.

Beaucoup de développeurs comprennent la sécurité côté code avant de la prendre au sérieux côté comptes. C'est une erreur. Parce que si tes accès tombent, ton code peut tomber avec.

GitHub : ce n'est pas juste un endroit où on pousse du code

Pour une développeuse, GitHub est bien plus qu'un dépôt. C'est souvent à la fois :

  • une vitrine,
  • un historique de travail,
  • un portefeuille de preuves,
  • un espace collaboratif,
  • et parfois une passerelle vers des déploiements automatisés.

Un compte GitHub mal sécurisé peut donc avoir des conséquences très concrètes : suppression ou modification de repos, accès à des secrets, altération de workflows CI/CD, compromission d'actions automatisées, ajout de clés ou de collaborateurs non autorisés.

La sécurité GitHub commence par des gestes simples mais non négociables :

  • activer la MFA,
  • vérifier régulièrement les appareils et sessions connectés,
  • contrôler les applications autorisées,
  • utiliser des clés SSH propres,
  • éviter les tokens créés "vite fait" puis oubliés,
  • revoir les permissions accordées aux intégrations.

Et surtout : comprendre avec quel compte on agit réellement.

Ça paraît évident, mais en pratique, entre plusieurs identités GitHub, plusieurs clés SSH, plusieurs machines, plusieurs repos, on peut vite créer une confusion dangereuse. Le sujet n'est pas seulement de "réussir à push". Le sujet est de savoir précisément qui pousse, avec quelle clé, depuis quel environnement.

La sécurité, ce n'est pas juste avoir accès. C'est garder le contrôle de cet accès.

SSH : pratique, propre, mais seulement si c'est bien géré

Beaucoup de développeurs passent à SSH parce que c'est plus fluide que HTTPS, et c'est souvent une bonne idée. Mais là encore, il ne suffit pas de générer une clé et d'oublier le sujet.

Une clé SSH doit s'inscrire dans une logique claire :

  • une clé identifiable,
  • une configuration cohérente,
  • un lien maîtrisé avec le bon compte,
  • et idéalement une passphrase.

Le vrai danger, ce n'est pas seulement la technique. C'est le flou.

Une machine avec plusieurs clés mal nommées. Un compte personnel mélangé avec un compte pro. Un alias SSH non documenté. Une clé par défaut qui pointe vers le mauvais profil. Et, des semaines plus tard, plus personne ne sait ce qui est réellement utilisé.

Quand on veut construire quelque chose de solide, il faut sortir du bricolage invisible. Même seule. Même sur un petit projet. Même "juste pour apprendre".

La sécurité commence aussi par l'hygiène numérique

On parle souvent de cybersécurité comme d'un sujet spectaculaire. En réalité, une grande partie de la sécurité des comptes dev relève surtout de l'hygiène.

Par exemple :

  • ne pas stocker ses secrets n'importe où,
  • ne pas exposer un fichier sensible dans un repo,
  • ne pas laisser traîner des tokens dans un terminal, une capture d'écran ou un README,
  • ne pas connecter aveuglément une application tierce à GitHub ou Google,
  • ne pas réutiliser la même adresse mail et le même mot de passe partout,
  • ne pas garder des accès anciens "au cas où".

L'hygiène, c'est aussi le nettoyage.

Avec le temps, on accumule des comptes inutilisés, des essais d'outils, des permissions anciennes, des intégrations oubliées. Et chaque oubli est un risque potentiel. Pas forcément énorme. Mais inutile.

Le bon réflexe, ce n'est pas de tout compliquer. C'est de réduire ce qui n'a pas besoin d'exister.

Ton téléphone fait partie de ta sécurité

On oublie souvent ce point : ton téléphone n'est pas en dehors de ton environnement dev. Il en fait partie.

Aujourd'hui, il sert à recevoir des codes MFA, valider des connexions, accéder à GitHub, lire les emails de sécurité, gérer les mots de passe, approuver des connexions, parfois même administrer un projet en déplacement.

Autrement dit : si ton téléphone est mal protégé, une partie de ta sécurité l'est aussi.

Concrètement, cela veut dire :

  • verrouillage sérieux de l'appareil,
  • mises à jour installées,
  • authentification biométrique ou code fort,
  • prudence avec les réseaux publics,
  • attention particulière aux applications sensibles.

Le mobile n'est pas un accessoire secondaire. C'est souvent une extension directe de ton identité numérique.

La sécurité, c'est aussi une question de crédibilité

Quand on construit une présence en ligne — blog, GitHub, portfolio, activité freelance, app en cours de création — la sécurité devient aussi un sujet de crédibilité.

Quel message envoies-tu si tu parles d'outils, de business, de création de projets, mais que tes propres comptes sont fragiles ?

Je ne parle pas d'être experte en sécurité offensive. Je parle d'être cohérente.

Une développeuse crédible, ce n'est pas seulement quelqu'un qui sait coder une interface propre. C'est quelqu'un qui comprend que son infrastructure personnelle mérite aussi d'être protégée. Surtout si elle veut construire sur le long terme.

Parce qu'au fond, sécuriser ses comptes dev, c'est protéger son travail, son temps, sa réputation, sa progression, et sa capacité à continuer sereinement.

Par où commencer, concrètement ?

Le plus important, c'est de ne pas transformer ce sujet en montagne mentale. Tu n'as pas besoin de tout refaire en une journée. Mais tu as besoin d'un plan simple et sérieux.

1. Sécurise ton email principal

Mot de passe unique, MFA activée, vérification des sessions et des options de récupération.

2. Sécurise GitHub

MFA, audit des appareils, des clés SSH, des applications autorisées et des tokens.

3. Mets de l'ordre dans tes identités

Quel compte pour quel usage ? Quelle clé pour quel compte ? Quel appareil pour quel contexte ?

4. Utilise un gestionnaire de mots de passe

Pas demain. Maintenant.

5. Fais un ménage de permissions

Supprime les accès inutiles, les intégrations oubliées, les comptes tests devenus permanents par accident.

6. Vérifie ce que tu exposes publiquement

Repo, README, captures, variables d'environnement, configuration locale, historique de commandes.

7. Documente un minimum ton setup

Pas forcément dans un roman. Mais assez pour ne pas te perdre toi-même dans trois mois.

La documentation n'est pas qu'un réflexe d'équipe. C'est aussi une forme d'autoprotection.

Ce que je retiens aujourd'hui

Plus j'avance, plus je trouve que la sécurité des comptes dev ressemble à beaucoup de choses importantes dans le travail technique : ce n'est pas spectaculaire, ce n'est pas toujours visible de l'extérieur, mais c'est ce qui évite des problèmes coûteux plus tard.

Tu n'as pas besoin d'être une grosse entreprise pour avoir de bonnes pratiques. Tu n'as pas besoin d'attendre d'avoir "réussi" pour protéger ce que tu construis. Et tu n'as pas besoin d'être experte cybersécurité pour traiter tes accès avec sérieux.

Sécuriser ses comptes dev, ce n'est pas un détail technique.

C'est une manière de dire : ce que je construis compte, donc je le protège.

Tu retrouveras d'autres guides pratiques dans la section Tech.