Aller au contenu principal
Gouvernance

Le pacte d'associés ne dit rien de la technique — et c'est un problème

Un pacte d'associés protège minutieusement le capital : qui peut vendre, à qui, à quel prix. Il ne dit presque jamais un mot de l'actif qui fait tourner l'entreprise. Six clauses manquantes, et ce qu'elles coûtent le jour d'une cession.

Photo de David Patiashvili David Patiashvili 10 min de lecture
Sommaire

    Un contrat très précis sur le capital, muet sur l’outil

    Prenez un pacte d’associés standard. Vous y trouverez une trentaine de pages soigneusement rédigées : inaliénabilité, préemption, agrément, sortie conjointe, obligation de sortie, anti-dilution, liquidation préférentielle, clauses de good et bad leaver, non-concurrence, engagement d’exclusivité du fondateur.

    Un travail sérieux, qui protège minutieusement une chose : le capital. Qui détient quoi, qui peut vendre, à qui, à quel prix, dans quel ordre.

    Cherchez maintenant ce que dit ce même pacte de l’actif qui fait effectivement tourner l’entreprise — le logiciel, la base de données, les accès, l’infrastructure. Dans la grande majorité des pactes que nous voyons passer, la réponse tient en une ligne générique sur la propriété intellectuelle, quand elle existe.

    Ce n’est pas un défaut de compétence des rédacteurs. Un avocat écrit ce qu’on lui décrit. Si personne autour de la table ne formule le sujet technique en termes de risque, il n’apparaît nulle part.

    Le problème, c’est que ce silence a un prix, et qu’il se paie toujours au même moment : la due diligence.

    Les six sujets qui manquent

    1. La titularité réelle des droits sur le code

    C’est le sujet numéro un, et le plus mal compris.

    En droit français, la cession de droits d’auteur ne se présume pas. Elle doit être écrite, et délimitée quant à son étendue, sa destination, son lieu et sa durée. Payer une facture de développement ne transfère aucun droit : cela paie une prestation.

    Conséquence concrète, que nous constatons régulièrement : une PME exploite depuis huit ans un logiciel métier dont elle n’a jamais acquis les droits. Le prestataire n’en a peut-être aucune intention hostile — souvent il n’y a jamais pensé non plus. Mais juridiquement, la société exploite un actif qui ne lui appartient pas.

    Le sujet se complique avec les intervenants successifs : freelances, stagiaires, alternants, développeurs d’une agence rachetée depuis. Chaque contribution est une œuvre, chaque œuvre a un auteur, chaque auteur devait céder ses droits par écrit.

    Ce que le pacte peut poser : l’engagement que la société soit et demeure titulaire des droits sur ce qu’elle exploite, et qu’aucun développement ne soit commandé sans clause de cession conforme. Nous avons détaillé le mécanisme dans notre article sur la propriété du code source.

    2. La détention des accès

    Question simple, réponse souvent embarrassante : qui détient le compte propriétaire du nom de domaine ?

    Puis les suivantes. Le compte d’hébergement est-il au nom de la société ou à celui d’un salarié ? Qui a la main sur la zone DNS ? Sur les certificats ? Sur le dépôt de code ? Sur le compte de facturation du fournisseur cloud ? Que se passe-t-il si la personne qui a créé ces comptes avec son adresse personnelle quitte l’entreprise en mauvais termes ?

    Un nom de domaine détenu par un prestataire est un moyen de pression absolu. Ce n’est pas une hypothèse d’école : nous consacrons un article entier au cas du prestataire injoignable, et l’accès est toujours le premier mur.

    3. La réversibilité

    Que se passe-t-il si votre prestataire principal cesse son activité demain ?

    Une clause de réversibilité oblige le prestataire à restituer, dans un format exploitable et dans un délai défini, tout ce qui permet à un tiers de reprendre : code source, documentation d’exploitation, procédures de déploiement, jeux de données, accès. Elle se complète d’un séquestre auprès d’un tiers de confiance quand l’enjeu le justifie.

    C’est une clause de contrat fournisseur, pas de pacte. Mais le pacte peut rendre obligatoire son insertion dans tout contrat critique — et le comité de gouvernance peut en vérifier l’existence une fois par an. Cela prend dix minutes en séance.

    4. La dépendance à une personne

    Les pactes traitent l’homme-clé, mais toujours le même : le dirigeant fondateur, avec engagement de présence et non-concurrence.

    Ils ignorent l’autre, qui est souvent le risque le plus immédiat : le développeur unique qui a écrit le système, qui seul sait pourquoi telle chose fonctionne, et dont le départ suspendrait toute évolution pendant six mois.

    Ce risque ne se traite pas par une clause — on ne retient personne par contrat. Il se traite par de la documentation, du partage de connaissance et un plan de continuité. Ce que le pacte peut faire, c’est exiger que le sujet soit suivi et présenté au moins une fois par an à l’organe de gouvernance. C’est le minimum, et c’est déjà beaucoup plus que rien.

    5. La sécurité et la conformité

    Un incident de sécurité ou un manquement au RGPD n’est plus un sujet purement technique : c’est un passif potentiel, avec un régime de sanctions et une obligation de notification.

    Le pacte prévoit habituellement des déclarations et garanties du cédant sur la régularité de la situation sociale, fiscale et juridique. La conformité au traitement des données personnelles y figure rarement, alors qu’elle relève exactement de la même logique : une affirmation vérifiable, dont l’inexactitude engage.

    6. L’usage de l’intelligence artificielle générative

    Sujet nouveau, déjà présent dans les questionnaires de due diligence les plus récents, et absent de la quasi-totalité des pactes existants.

    Deux questions se posent. Quelle part du code exploité a été produite avec un assistant d’IA, et sous quelles conditions de licence ? Et quelles données de l’entreprise transitent vers des services tiers, avec quelles garanties sur leur réutilisation ?

    Aucune des deux n’appelle une réponse alarmiste — nous avons développé notre position sur l’hébergement de l’IA en Europe. Elles appellent en revanche une politique écrite, que quelqu’un puisse présenter sans improviser.

    Ce que ça coûte, concrètement

    Une faiblesse sur ces sujets ne fait presque jamais échouer une opération. Elle la déforme, et toujours dans le même sens.

    Ce qu’on découvreCe que ça devient dans la négociation
    Droits sur le code non cédésGarantie d’actif et de passif renforcée, parfois séquestre d’une partie du prix
    Nom de domaine détenu par un tiersCondition suspensive de régularisation avant signature
    Dépendance à un développeur uniqueClause de rétention, retenue sur prix, ou décote
    Absence de réversibilité chez le prestataire critiqueAudit complémentaire à la charge du cédant, calendrier allongé
    Conformité RGPD non documentéeGarantie spécifique, plafond de garantie relevé

    Le point commun de ces cinq lignes : le coût est supporté par le cédant, et il est bien supérieur à ce qu’aurait coûté la régularisation faite à froid. Une cession de droits signée en amont coûte quelques centaines d’euros ; découverte pendant une due diligence, elle devient un moyen de pression sur le prix.

    C’est ce que nous décrivons plus largement dans notre article sur ce que l’investisseur cherche vraiment.

    Où écrire quoi

    Toutes ces clauses n’ont pas leur place au même endroit. Répartition simple :

    Dans les contrats fournisseurs : la cession de droits, la réversibilité, le séquestre, les engagements de niveau de service, la propriété des comptes. C’est là que ça se joue réellement.

    Dans le pacte d’associés : l’engagement que ces clauses existent, la déclaration de titularité des actifs exploités, et l’obligation d’informer l’organe de gouvernance de tout événement affectant ces actifs.

    Dans le règlement du comité de gouvernance : la revue annuelle. Une page à l’ordre du jour, une fois par an, avec quatre points — titularité, accès, dépendances, incidents. C’est le dispositif le moins coûteux et le plus efficace des trois.

    Pourquoi cela relève de la gouvernance

    Un dernier mot sur le fond.

    On classe spontanément ces sujets dans l’opérationnel, parce qu’ils sont techniques. C’est une erreur de rangement. Une société qui exploite un logiciel dont elle ne détient pas les droits, dont le nom de domaine appartient à un tiers, et dont un seul développeur connaît le fonctionnement, ne présente pas un problème technique : elle présente un risque d’exploitation, du même ordre qu’un client représentant 40 % du chiffre d’affaires ou qu’un bail commercial non renouvelé.

    Ces risques-là, personne ne conteste qu’ils relèvent du conseil. Les autres devraient y arriver aussi — et il suffit, pour cela, que quelqu’un dans la pièce sache les formuler dans le langage du risque plutôt que dans celui de l’ingénierie.


    Vous préparez une levée, une entrée au capital ou une cession, et vous voulez savoir ce qu’une due diligence trouvera avant qu’elle ne le trouve ? C’est précisément l’objet de notre audit technique. Parlons-en.

    Partager

    Retrouvez nos articles en priorité dans vos résultats Google en nous ajoutant à vos sources préférées.

    Ajouter aux sources préférées

    En savoir plus

    Nos prestations associées

    Audit

    Audit technique

    Évaluation indépendante de votre stack — code, sécurité, dette, scaling, coûts. Rapport actionnable, pas un PDF qui dort.

    En savoir plus