Le risque ne commence pas avec la lettre de démission. Il commence des semaines plus tôt, quand l'ingénieur est encore connecté à tous les dépôts de code, a encore un accès complet aux documents de conception, et pense déjà à la suite. Cette période est discrète, ne déclenche aucune alerte, et ressemble à un mardi ordinaire. C'est aussi le moment où une startup perd la trace la plus claire de qui a vraiment construit quoi.
Ce qui part vraiment par la porte
C'est rarement le produit fini. Le dépôt de production va généralement bien: il a un historique de commits, un vrai journal des modifications, et plus d'une personne peut en témoigner. Ce qui disparaît, c'est tout ce qui l'entoure. Un dépôt privé créé pour un premier prototype avant même que le dépôt "officiel" existe. Un document de conception collé dans un e-mail personnel parce que Slack était en panne ce jour-là. Une branche que personne n'a fusionnée parce que la fonctionnalité a été mise de côté, mais qui contient encore la première version fonctionnelle d'une idée que l'entreprise a ensuite lancée sous un autre nom. Rien de tout cela ne semble important tant que la personne fait partie de l'équipe. Tout cela devient contesté le jour où elle n'en fait plus partie.
Un cofondateur technique qui part après un désaccord est la version la plus aiguë de ce problème. Deux personnes peuvent se souvenir des six mêmes mois de manière complètement différente, et une fois la relation rompue, il n'existe plus de récit partagé de qui a écrit quelle ligne en premier, dont l'esquisse est devenue l'architecture, ou quand une idée donnée a réellement pris forme. Ce qui reste, c'est un souvenir contre un autre souvenir, ce qui n'est pas une preuve.
Cela ne concerne pas seulement les fondateurs. Un prestataire qui a construit la première version d'une fonctionnalité avant d'être embauché à temps plein. Un stagiaire dont le projet d'été est devenu discrètement un élément central du produit. Un freelance qui a dessiné le premier schéma d'architecture. Tous laissent le même type de vide derrière eux, généralement sans que personne ne le remarque jusqu'à ce qu'un litige force quelqu'un à chercher une preuve qui n'a jamais été conservée.
Pourquoi sceller "aux grandes étapes" laisse la faille ouverte
La plupart des équipes techniques qui y pensent y pensent au mauvais moment. Une version est taguée. Un contrat est signé. C'est ce qui est scellé, si tant est que quelque chose le soit. La branche exploratoire qui a façonné la version, le premier prototype qui a prouvé que l'idée était même viable, le document de conception interne sur lequel la version repose vraiment: tout cela reçoit rarement le même traitement, parce que personne ne pensait à un départ pendant qu'on écrivait encore du code ensemble. C'est exactement l'inverse de ce qu'il faudrait faire. Le matériel avec la trace écrite la plus faible est justement celui dont un ingénieur qui part se souvient le plus clairement, et pour lequel il a souvent l'instinct le plus fort de revendiquer le crédit.
Ce que le scellement continu établit réellement
La solution n'est pas une équipe juridique plus grande. C'est de traiter le scellement comme une part ordinaire de la manière dont le travail technique est sauvegardé, et non comme une étape réservée aux lancements et aux signatures. En pratique, cela veut dire une habitude aussi simple qu'une fusion vers la branche principale: le code source scellé à un rythme régulier plutôt qu'uniquement au moment de la version, un document de conception scellé le jour où il est partagé avec l'équipe plutôt que le jour où il est finalisé, un premier prototype scellé la semaine où il tourne pour la première fois plutôt que des mois plus tard, si jamais. Rien de tout cela ne dépend du fait de se souvenir qu'un départ pourrait survenir. Cela doit simplement déjà faire partie de la manière dont l'équipe travaille. En vertu de l'article 41 du règlement eIDAS, un horodatage électronique qualifié bénéficie d'une présomption d'exactitude quant à la date et l'heure qu'il indique, et de l'intégrité des données qu'il couvre. En Suisse, une signature délivrée par un prestataire accrédité ZertES a la même valeur juridique qu'une signature manuscrite. Aucun des deux cadres ne se soucie de savoir qui est encore employé quand un litige finit par apparaître. Tous deux se soucient de ce qui a été enregistré et quand, ce qui est justement la partie de l'histoire qui ne change pas selon qui la raconte.
Imaginons deux fondateurs qui construisent ensemble la première version fonctionnelle d'un produit, puis se séparent mal dix-huit mois plus tard. Si le premier prototype et le document de conception qui y a mené ont été scellés la semaine où ils ont été écrits, il existe un enregistrement daté et inviolable, indépendant de la mémoire ou de la relation actuelle de l'un ou l'autre. S'ils ne l'ont pas été, le litige se résume à celui qui est le plus convaincant, une position dans laquelle aucun des deux fondateurs ne devrait vouloir se trouver.
Ce que cela ne fait pas
Le scellement ne remplace pas un contrat de travail ni une clause de cession de propriété intellectuelle, et il ne tranche pas un litige à lui seul. Une entreprise a toujours besoin des accords sous-jacents qui établissent d'abord à qui appartient le travail produit. Ce que le scellement ajoute, c'est l'enregistrement de preuve dont un litige a réellement besoin une fois ces accords en place: la preuve de ce qui existait, sous quelle forme, et quand, que ni l'une ni l'autre partie ne peut discrètement réécrire une fois la relation terminée.
En faire une habitude avant le départ, pas après
Le jour où quelqu'un donne sa démission, il est déjà trop tard pour commencer à sceller le travail qui comptait le plus. Les startups qui évitent ce type de conflit sont celles qui ont fait du scellement une part de la façon dont elles sauvegardent leur travail technique dès le départ, tout comme elles ont fait du contrôle de version une part de la façon dont elles l'écrivent. Voyez comment cela fonctionne pour les équipes logicielles et IP avant que le prochain départ, prévu ou non, ne rende la question urgente.
