Juridique

1. Premier principe : qui protège-t-on ?

Les données, la continuité et l’autonomie du Client doivent survivre à toute relation commerciale.

Control-C ne se contente pas de concéder une licence logicielle. Elle délègue une responsabilité de garde. Le présent accord encode ce devoir afin qu’il survive aux changements de direction, aux chocs de marché et aux bonnes intentions qui s’essoufflent.

2. Définition du modèle de partenariat (ancrer la structure)

2.1 White-Label Stewardship Partnership (WLSP)

Un White-Label Stewardship Partnership (WLSP) est une relation dans laquelle :

• Le Partenaire exploite une instance auto-hébergée de Control-C.
• Le Partenaire contrôle la relation commerciale avec les clients finaux.
• Control-C conserve des obligations de supervision custodiale afin de protéger la survivabilité des clients.
• Les clients peuvent intégrer des plateformes tierces (par exemple Xero) dans le cadre d’une autorité déléguée.

Cette définition empêche les requalifications ultérieures (« simple revendeur », « simple infrastructure »).

3. Pacte de stewardship (cœur éthique)

3.1 Devoir de stewardship

Le Partenaire reconnaît expressément que :

• Il agit en qualité de dépositaire des données, et non de propriétaire, des données client.
• Son rôle inclut un devoir de diligence, de continuité et de réversibilité.
• L’optimisation commerciale ne doit jamais compromettre de manière substantielle :
  • L’intégrité des données
  • La récupérabilité
  • Les droits de sortie du client

3.2 Clause de primauté du client

En cas de conflit entre :

• Les intérêts commerciaux du Partenaire
• La durabilité de la plateforme
• La survivabilité des données client

La survivabilité du client prévaut.

4. Contrôles techniques et opérationnels (là où les principes deviennent réels)

4.1 Exigences d’hébergement et d’architecture

Les partenaires doivent :

• Exécuter Control-C sur une infrastructure documentée et reproductible.
• Maintenir des sauvegardes automatisées quotidiennes de :
  • Datastores Control-C
  • Configuration
  • Matériel de chiffrement (le cas échéant)
• Prendre en charge l’export dans des formats ouverts et documentés (au minimum un dump Postgres et le schéma).

Control-C se réserve le droit d’auditer les schémas d’architecture, pas uniquement le code.

4.2 Gouvernance des fonctionnalités et intégrité produit

• Control-C définit une matrice de capacités (fonctionnalités activées et désactivées).
• Le Partenaire ne peut pas :
  • Supprimer les outils de sortie client
  • Obscurcir les workflows de reprise
  • Présenter à tort une parité fonctionnelle avec les offres cœur de Control-C
• Toute personnalisation doit :
  • Être documentée de manière déclarative
  • Être réversible sans perte de données client

5. Garanties de survivabilité client (le cœur)

5.1 Droit à la continuité

Chaque client final doit conserver la capacité de :

• Récupérer une copie complète et exploitable de ses données.
• Se reconnecter à :
  • Un autre partenaire Control-C
  • Control-C en direct
  • Un environnement autogéré

Aucune économie de prise d’otage.

5.2 Dispositifs d’escrow et de transition

Les partenaires doivent accepter un ou plusieurs des mécanismes suivants :

• Escrow de code (pour les extensions spécifiques au partenaire)
• Escrow chiffré des identifiants (pour les secrets appartenant au client)
• Une voie de récupération « break glass » détenue par Control-C

Déclenché automatiquement en cas de :

• Insolvabilité
• Résiliation de licence
• Manquement substantiel
• Interruption prolongée du service

Sans délais discrétionnaires.

6. Changement d’activité et dispositions de fin de vie

6.1 Changement de contrôle

Si le Partenaire fait l’objet d’une acquisition, d’une fusion, d’un changement de contrôle majoritaire, ou d’un pivot stratégique l’éloignant des services de données, il doit :

• Notifier Control-C à l’avance.
• Fournir aux clients des options de continuité claires, des délais et des parcours de migration.

Le silence constitue un manquement.

6.2 Sortie ou défaillance du partenaire

En cas de résiliation (volontaire ou involontaire) :

• Le Partenaire maintient le service pendant une période de transition définie (par exemple 90 jours).
• Control-C peut intervenir pour aider à la migration et assumer un contrôle custodial temporaire uniquement pour protéger les clients.
• Pas de tarification de rançon. Pas de verrouillage via « services professionnels ».

7. Code d’éthique (court, net, opposable)

Les partenaires s’engagent à :

1. Ne jamais mettre sciemment des clients en danger pour un gain à court terme.
2. Communiquer les défaillances tôt et clairement.
3. Préserver la réversibilité dans toutes les décisions techniques.
4. Éviter les dark patterns, la vente groupée forcée ou la friction de sortie.
5. Traiter les données client comme une confiance prêtée, et non comme un actif.

La violation de ce code d’éthique constitue une violation du présent accord.

8. Supervision, audit et « droit de care »

Control-C conserve le droit de :

• Mener des revues périodiques de stewardship.
• Demander des preuves de :
  • Intégrité des sauvegardes
  • Exercices de restauration
  • Préparation à la réponse aux incidents
• Intervenir uniquement pour protéger les clients, et non pour concurrencer.

9. Déclaration d’intention

Ce partenariat existe pour garantir que les entreprises qui s’appuient sur des systèmes numériques ne soient jamais abandonnées par eux. Le succès commercial est bienvenu. L’abandon des clients ne l’est pas.

10. Ce que ce cadre accomplit sans le dire

Sans l’énoncer explicitement, ce cadre :

• Filtre tôt les partenaires de mauvaise foi.
• Force la maturité opérationnelle.
• Fait de Control-C le centre de gravité éthique.
• Positionne Control-C comme une infrastructure de continuité, pas de commodité.

11. Lignage de la plateforme, stewardship des mises à jour et continuité centrale

11.1 Réplication de continuité centrale (non négociable)

Toutes les instances hébergées par le Partenaire doivent prendre en charge une réplication sécurisée et automatisée vers un Datastore Central de Continuité géré par Control-C.

Caractéristiques clés :

• Accès en lecture seule pour Control-C en fonctionnement normal.
• Chiffrement en transit et au repos.
• Périmètre :
  • Données client
  • Métadonnées
  • Index de reprise
  • Preuves d’intégrité (hashes, manifestes)

Ce datastore existe uniquement pour :

• Valider la récupérabilité.
• Permettre des scénarios de survie client.
• Fournir une vérification indépendante des sauvegardes.

Pas d’analyses. Pas de monétisation. Pas de surveillance.

11.2 La réplication comme condition de licence

Le Partenaire reconnaît que :

• La réplication centrale est une condition de la licence en marque blanche.
• La désactivation ou une dégradation significative de la réplication :
  • Nécessite une approbation écrite.
  • Doit être limitée dans le temps.
  • Doit inclure une notification client si la situation se prolonge.

Une défaillance silencieuse constitue un manquement substantiel.

12. Actualité logicielle et intégrité opérationnelle

12.1 Engagement de version supportée

Les partenaires doivent opérer uniquement sur des versions Control-C supportées, dans la tolérance de décalage définie (N-2 maximum).

Control-C définit :

• Les calendriers de fin de support.
• Les SLA de correctifs de sécurité.
• Les fenêtres de mise à niveau obligatoires pour les correctifs critiques.

Exécuter un logiciel obsolète est considéré comme un risque pour la continuité client, pas comme une préférence technique.

12.2 Modèle de responsabilités de mise à jour (lignes claires)

12.3 Opérabilité et signalisation de santé

Les partenaires doivent exposer une télémétrie de santé de base, notamment :

• Disponibilité
• Taux de succès des jobs
• Fraîcheur des sauvegardes
• Reporting de version
• Statut de réplication

Ces signaux peuvent être via API, en push ou pull, et rester légers, mais ils doivent exister.

13. Droit d’assistance (clause de devoir de diligence)

13.1 Droit de remédiation assistée

Si une instance partenaire ne réplique plus, est dangereusement obsolète, devient non opérable, ou met en risque la continuité client, Control-C peut :

• Notifier le Partenaire.
• Proposer une assistance directe.
• Exiger un plan de remédiation assorti d’échéances.

Sans résolution, Control-C peut déclencher une intervention protectrice strictement limitée au rétablissement de l’opérabilité ou à la transition client.

Il ne s’agit pas d’une clause de prise de contrôle. Il s’agit d’une clause de devoir de diligence.

14. Continuité de la plateforme lors de la sortie d’un partenaire

En cas de fin de partenariat ou de défaillance du Partenaire :

• Le Datastore Central de Continuité devient la référence de reprise faisant autorité.
• Control-C peut :
  • Valider le dernier état « bon » connu.
  • Aider au re-homing (réaffectation) des clients.
  • Reconstituer des environnements si requis contractuellement.

Les clients ne repartent jamais de zéro.

15. Pourquoi cela complète la boucle de stewardship

Ces clauses protègent simultanément trois niveaux :

1. Survie client
2. Intégrité de la plateforme dans le temps
3. Confiance de l’écosystème (partenaires, régulateurs, plateformes amont comme Xero)

La continuité ne concerne pas uniquement les données. Elle concerne la continuité du devoir de diligence.