Outsourcing IT white-label : gérer la confidentialité sans faux pas

Un seul email mal envoyé peut faire perdre un client

Une entreprise IT italienne remporte un contrat de 200k€ pour développer un ERP sur mesure. Faute de ressources internes suffisantes, elle sous-traite le développement à un partenaire externe. Les livraisons sont ponctuelles, le code est solide.

Puis, lors d'une revue de code, le client final ouvre GitHub et tombe sur des commits signés avec une adresse @partenaire-externe.it. En trente secondes, il comprend que le travail n'a pas été réalisé en interne. En une semaine, il renégocie le contrat en contournant le prestataire d'origine.

Ce scénario n'est pas fictif. Il se répète sous des formes variées : un espace Slack mal configuré, un Jira accessible, un pied de page d'email oublié. L'outsourcing IT white-label ne fonctionne que si la gestion de la confidentialité est systématique — pas laissée à la bonne volonté des individus.

---

Où la confidentialité se brise : les points critiques

1. Artefacts de code et métadonnées

Git est le premier endroit où les identités fuient. Chaque commit porte un user.name et une user.email. Si le partenaire ne configure pas correctement le dépôt, ses vraies identifiants se retrouvent dans l'historique.

Solution opérationnelle :

# Dans le dépôt du projet white-label, imposer une identité neutre
git config user.name "Dev Team"
git config user.email "dev@client-final.com"

Mieux encore : définir un .gitconfig de projet et ajouter un hook pre-commit qui bloque les pushs si user.email ne correspond pas au domaine convenu.

#!/bin/sh
# .git/hooks/pre-commit
EMAIL=$(git config user.email)
if [[ "$EMAIL" != *"@domaine-convenu.com" ]]; then
  echo "ERREUR : email Git non autorisée ($EMAIL). Configurez user.email."
  exit 1
fi

2. Communications écrites

Les emails constituent le deuxième vecteur de fuite. Un fil de discussion initié depuis developpeur@partenaire.fr et transféré par inadvertance au client final expose tout.

Les règles opérationnelles sont simples, mais doivent être formalisées :

Le partenaire utilise exclusivement des alias email sur le domaine du prestataire principal (ex. : dev@prestataire-principal.fr).
Aucun outil de communication du partenaire (espace Slack, tenant Teams) n'est accessible au client final.
Toutes les réunions avec le client final passent par le prestataire principal, seul interlocuteur visible.

3. Documentation technique

Les documents d'architecture, les diagrammes et les spécifications portent souvent des filigranes, des noms d'auteurs et des métadonnées. Un PDF exporté depuis le Confluence du partenaire contient dans ses métadonnées le nom de son organisation.

# Exemple : suppression des métadonnées avec PyPDF2 avant livraison
import PyPDF2

def strip_metadata(input_path, output_path):
    reader = PyPDF2.PdfReader(input_path)
    writer = PyPDF2.PdfWriter()
    for page in reader.pages:
        writer.add_page(page)
    writer.add_metadata({})
    with open(output_path, 'wb') as f:
        writer.write(f)

La sanitisation des documents doit figurer comme étape obligatoire dans la checklist de livraison — pas comme une bonne pratique facultative.

4. Infrastructure et DNS

Si le partenaire gère l'infrastructure, les enregistrements DNS, les certificats SSL ou les labels des conteneurs peuvent révéler l'identité réelle. Un whois sur le domaine de staging ou un docker inspect sur l'image peuvent suffire.

Contre-mesures :

Les domaines de staging doivent être enregistrés au nom du prestataire principal ou d'une entité neutre.
Les images Docker doivent être reconstruites avec des labels neutres avant la livraison.
Les certificats SSL doivent être émis sur des domaines contrôlés par le prestataire principal.

5. Le NDA : nécessaire, mais pas suffisant

Le NDA est le point de départ, pas d'arrivée. Un NDA bien rédigé pour l'outsourcing IT white-label doit couvrir :

Une définition explicite des « informations confidentielles » (noms de clients, détails de projet, technologies utilisées).
Une clause de non-sollicitation interdisant tout contact direct avec le client final pendant une période définie (généralement 24 à 36 mois après la fin du projet).
Des pénalités financières proportionnelles à la valeur du contrat, pas symboliques.
Une clause d'audit : le prestataire principal a le droit de vérifier les procédures de sécurité du partenaire.

Un modèle de NDA générique téléchargé en ligne ne couvre pas ces points avec la précision nécessaire.

---

Un modèle opérationnel en compartiments étanches

La structure qui fonctionne le mieux dans les environnements B2B multi-partenaires est le modèle en compartiments étanches :

[Client final]
      |
[Prestataire principal]  ← seul interlocuteur visible
      |
  ┌───┴───┐
[Partenaire A] [Partenaire B]  ← invisibles pour le client

Règles de ce modèle :

Ségrégation des accès : le partenaire n'accède qu'aux dépôts et environnements strictement nécessaires à son périmètre. Zéro accès au CRM, aux outils de ticketing du client ou aux canaux Slack partagés avec le client.
Proxy de communication : toutes les demandes techniques du client transitent par un chef de projet interne au prestataire principal, qui les traduit et les délègue. Le partenaire ne répond jamais directement au client.
Revue des artefacts : chaque livrable — code, documentation, images — est inspecté par le prestataire principal avant d'atteindre le client. La checklist est écrite, pas mémorisée.
Onboarding formalisé du partenaire : avant tout projet, le partenaire reçoit un document opérationnel précisant l'identité Git à utiliser, les domaines email, les outils autorisés et interdits, et les procédures de livraison. Il signe une lettre d'acceptation.

---

Take-away opérationnel

La confidentialité dans l'outsourcing IT white-label ne se gère pas par la confiance — elle se gère par les processus. Les fuites d'information sont presque toujours involontaires : elles résultent de procédures absentes ou non formalisées.

Quatre actions à mettre en place immédiatement :

Un hook pre-commit bloquant les emails Git non autorisées.
Des alias email obligatoires pour toutes les communications vers le client final.
Une checklist écrite de sanitisation des artefacts avant chaque livraison.
Un NDA spécifique à l'outsourcing IT white-label avec clause de non-sollicitation et pénalités proportionnelles.

Si l'un de ces quatre points manque, le risque d'exposition est réel — quelle que soit la qualité du partenaire.

---

Evviva Group opère comme partenaire technologique white-label pour les agences et les intégrateurs système. Si vous structurez ou consolidez votre modèle d'outsourcing IT, nous sommes disponibles pour en discuter.