This audit will not fix anything by itself. It shows you where you are exposed. You need a spreadsheet, about 30 minutes, and access to your own email and billing records.
The rule behind the audit
For every service you use, four things should be true:
- The account is in your name (your company, your email address, not a contractor's).
- Billing goes to you (your card or your invoice, not reimbursed through someone else).
- You hold an admin or owner role, not just a user role.
- You control the recovery path: the 2FA device, the recovery email and the phone number are yours.
If any of the four is missing, you have a dependency. It is invisible until the day it becomes urgent.
Step 1: List everything
Make one row per service. Do not trust memory. Check these sources:
- Your accounting records and card statements for the past 12 months (recurring charges reveal forgotten tools)
- The inbox of your main address, searching for "invoice", "receipt" and "welcome"
- Your website's source or settings, to see which third-party services it loads
Typical categories:
- Domain name and DNS
- Hosting or cloud (OVH, AWS, a managed host, a VPS)
- Website, CMS or shop (WordPress, Shopify, PrestaShop, Odoo)
- Email (Google Workspace, Microsoft 365, a host's mailboxes)
- Analytics and marketing (Google Analytics, Search Console, Ads, Meta, Mailchimp)
- Payments (Stripe, PayPal, your bank's provider)
- Source code (GitHub, GitLab, Bitbucket)
- App store accounts (Apple Developer, Google Play)
- Third-party APIs (maps, SMS, email sending, AI)
- Business tools (CRM, helpdesk, project tracker, accounting)
Step 2: Fill in four columns for each row
| Service | Account owner (name/email) | Who pays | Who is admin | Who controls recovery |
|---|---|---|---|---|
| Example: domain |
Mark each cell green (you), orange (shared or unclear) or red (someone else, or unknown).
Step 3: Check the high-risk items first
Your domain name. This is the most important asset on the list. Look up the registrant of your domain with a WHOIS lookup (some registrars hide details, in which case log into the registrar). Questions to answer: Who holds the registrar account? Which email receives the renewal reminders? Is auto-renewal on? If the registrar account belongs to your agency, you rent your own name.
Your hosting and cloud accounts. A very common situation: a freelancer created the AWS or hosting account with their own email and added the company card, or worse, their own card, re-invoiced to you. You may be paying, but you cannot log in.
Your source code. Is the repository in an organization you control? If the code lives in a personal account of your developer, you may not have the right to access it, let alone the ability to hand it to someone else.
Your payment provider. The Stripe or PayPal account should be in your company's legal name. Changing it later is possible but painful.
Your Google accounts. Analytics, Search Console and Ads often get set up under an agency's login. When the relationship ends, years of data can go with it.
Step 4: Check the "single person" risks
Even with accounts in your name, one person can be a single point of failure. Look for:
- Passwords stored in one person's head, notebook or private password manager
- 2FA codes going to one person's phone
- A shared mailbox that only one person can read
- A "master" admin who has left or is about to leave
Step 5: Fix in priority order
- Domain first. Move registrant and registrar access to your company.
- Anything that makes money (shop, payments, booking).
- Anything that holds your data (CRM, accounting, cloud storage).
- Everything else.
For each red item, the fix is usually one of three:
- Transfer ownership (many platforms have an official procedure).
- Add yourself as owner, then remove or reduce the other person's role.
- Recreate under your name and migrate, when transfer is not possible. For SaaS exits that go deeper than account ownership, see leaving a SaaS without losing your data.
Do this calmly and in writing. Most providers cooperate if asked politely and early. It is much harder in the middle of a dispute.
Too many red cells?
If the spreadsheet already shows dependencies you cannot unwind alone, we can walk the high-risk rows with you and plan the transfers under accounts you own.
What a healthy setup looks like
- Accounts created with a company email address (not a personal one), ideally a role address such as it@yourcompany.com that several people can access
- Service providers invited as limited, revocable users
- A shared password manager with at least two administrators
- A short document listing every service, who owns it and where recovery details are stored
- A yearly review of this list (add it to your calendar now)
Quick self-test
Answer yes or no:
- I can log into my domain registrar account today
- I can log into my hosting or cloud account today
- I can access my source code without asking anyone
- My payment provider account is in my company's name
- Two people can recover our main accounts
- If my developer vanished, a new one could start with the access I hold
Every "no" is a conversation to have this month, not after an incident.
From audit to a clean ownership map
If you want a second pair of eyes on the spreadsheet, write us. We answer on substance.
Cet audit ne répare rien à lui seul. Il montre où vous êtes exposés. Il vous faut un tableur, environ 30 minutes, et l'accès à votre messagerie et à vos factures.
La règle derrière l'audit
Pour chaque service que vous utilisez, quatre points doivent être vrais:
- Le compte est à votre nom (votre société, votre adresse email, pas celle d'un prestataire).
- La facturation vous revient (votre carte ou votre facture, pas un remboursement via quelqu'un d'autre).
- Vous avez un rôle admin ou propriétaire, pas seulement un rôle utilisateur.
- Vous contrôlez le chemin de récupération: l'appareil 2FA, l'email de récupération et le numéro de téléphone sont à vous.
Si l'un des quatre manque, vous avez une dépendance. Elle reste invisible jusqu'au jour où elle devient urgente.
Étape 1: tout lister
Une ligne par service. Ne vous fiez pas à la mémoire. Vérifiez ces sources:
- La compta et les relevés de carte des 12 derniers mois (les prélèvements récurrents révélent les outils oubliés)
- La boîte de votre adresse principale, en cherchant « facture », « reçu » et « bienvenue » / « welcome »
- Le code ou les réglages du site, pour voir quels services tiers il charge
Catégories typiques:
- Nom de domaine et DNS
- Hébergement ou cloud (OVH, AWS, hébergeur managé, VPS)
- Site, CMS ou boutique (WordPress, Shopify, PrestaShop, Odoo)
- Messagerie (Google Workspace, Microsoft 365, boîtes de l'hébergeur)
- Analytics et marketing (Google Analytics, Search Console, Ads, Meta, Mailchimp)
- Paiements (Stripe, PayPal, prestataire de votre banque)
- Code source (GitHub, GitLab, Bitbucket)
- Comptes stores (Apple Developer, Google Play)
- APIs tierces (cartes, SMS, envoi d'emails, IA)
- Outils métier (CRM, helpdesk, suivi de projet, compta)
Étape 2: quatre colonnes par ligne
| Service | Propriétaire du compte (nom/email) | Qui paie | Qui est admin | Qui contrôle la récupération |
|---|---|---|---|---|
| Exemple: domaine |
Marquez chaque cellule en vert (vous), orange (partagé ou flou) ou rouge (quelqu'un d'autre, ou inconnu).
Étape 3: les points à risque d'abord
Votre nom de domaine. C'est l'actif le plus important de la liste. Vérifiez le titulaire via un WHOIS (certains registrars masquent les détails: connectez-vous alors au compte registrar). Questions: Qui détient le compte registrar? Quel email reçoit les rappels de renouvellement? Le renouvellement auto est-il actif? Si le compte registrar appartient à votre agence, vous louez votre propre nom.
Vos comptes d'hébergement et de cloud. Cas fréquent: un freelance a créé le compte AWS ou hébergeur avec son email et a ajouté la carte de l'entreprise, ou pire la sienne, refacturée. Vous payez peut-être, mais vous ne pouvez pas vous connecter.
Votre code source. Le dépôt est-il dans une organisation que vous contrôlez? Si le code vit dans le compte personnel du développeur, vous n'avez peut-être ni le droit d'accès, ni la possibilité de le transmettre.
Votre prestataire de paiement. Le compte Stripe ou PayPal doit être au nom légal de votre société. Le changer plus tard est possible, mais douloureux.
Vos comptes Google. Analytics, Search Console et Ads sont souvent créés sous le login d'une agence. Quand la relation s'arrête, des années de données peuvent partir avec.
Étape 4: le risque « une seule personne »
Même avec des comptes à votre nom, une personne peut être un point de défaillance unique. Cherchez:
- Des mots de passe dans la tête, le carnet ou le gestionnaire privé d'une seule personne
- Des codes 2FA qui arrivent sur le téléphone d'une seule personne
- Une boîte partagée que une seule personne peut lire
- Un admin « maître » déjà parti ou sur le départ
Étape 5: corriger par priorité
- Le domaine d'abord. Transférez le titulaire et l'accès registrar à votre société.
- Tout ce qui fait rentrer de l'argent (boutique, paiements, réservation).
- Tout ce qui détient vos données (CRM, compta, stockage cloud).
- Le reste.
Pour chaque case rouge, la correction est en général l'une de ces trois:
- Transférer la propriété (beaucoup de plateformes ont une procédure officielle).
- Vous ajouter comme propriétaire, puis retirer ou réduire le rôle de l'autre.
- Recréer à votre nom et migrer, quand le transfert est impossible. Pour les sorties de SaaS plus larges que la seule propriété des comptes, voir sortir d'un SaaS sans perdre ses données.
Faites-le calmement et par écrit. La plupart des prestataires coopèrent si on demande tôt et poliment. C'est bien plus dur au milieu d'un conflit.
Trop de cases rouges ?
Si le tableur montre déjà des dépendances que vous ne pouvez pas dénouer seuls, on peut passer les lignes à risque avec vous et planifier les transferts sous des comptes que vous possédez.
À quoi ressemble une organisation saine
- Comptes créés avec une adresse email d'entreprise (pas personnelle), idéalement une adresse de rôle comme it@votresociete.com accessible à plusieurs personnes
- Prestataires invités comme utilisateurs limités et révocables
- Un gestionnaire de mots de passe partagé avec au moins deux administrateurs
- Un court document listant chaque service, qui le possède et où sont les détails de récupération
- Une revue annuelle de cette liste (ajoutez-la à votre calendrier maintenant)
Auto-test rapide
Répondez oui ou non:
- Je peux me connecter au compte registrar de mon domaine aujourd'hui
- Je peux me connecter à mon compte hébergeur ou cloud aujourd'hui
- Je peux accéder à mon code source sans demander à personne
- Le compte du prestataire de paiement est au nom de ma société
- Deux personnes peuvent récupérer nos comptes principaux
- Si mon développeur disparaissait, un nouveau pourrait démarrer avec les accès que je détiens
Chaque « non » est une conversation à avoir ce mois-ci, pas après un incident.
De l'audit à une carte de propriété propre
Si vous voulez un second regard sur le tableur, écrivez-nous. On répond sur le fond.