GitLab est une plate-forme d’hébergement de code, directement concurrente de GitHub, l’incontournable solution Open Source. Elle héberge non seulement du code, mais aussi des outils de monitoring et de performances qui aident les équipes projets à optimiser leur production et à anticiper sur d’éventuels problèmes d’exploitation.

En fait la seule vraie motivation de GitLab (d’où son nom) est justement d’être une alternative à GitHub, que certains analystes estiment trop monopolistique, comme s’il n’existait qu’une seule vérité dans ce domaine.

Raisonnement qu’on sans doute dû se faire quelques grands clients  comme Intel et Red Hat, mais aussi Next Web (TNW), un portail de veille technologique, mais aussi organisateur d’évènements et fournisseur de services dont une plate-forme de jeux (on lui doit SquadCoach.com que les connaisseurs reconnaîtront).

C’est d’ailleurs Next Web qui a révélé l’ « affaire » GitLab, en indiquant qu’elle avait perdu récemment toute ses données de production. Entendons-nous bien, pas les données de production des applications une fois les développements terminés, mais les données qui permettent aux développeurs de retrouver leurs fichiers, sources, exécutables, résultats de tests, API retenues, etc. De sorte que Next Web, tout comme Red Hat et Intel, s’est retrouvé devant l’alternative soit de récupérer ses fichiers, soit de tout recommencer à partir des données locales qu’il aurait eu la bonne idée de sauvegarder en complément.

92 % des données récupérées

GitLab a lancé fort heureusement un processus de récupération de ces données, mais nous trouvons étonnant que 24 heures après l’évènement, il n’ait pu récupérer que 92 % de ces données. C’est surtout cela qui n’a pas de sens. Car ou bien GitLab dispose d’un système de backup/restore normal, comme n’importe quel prestataire « sérieux » ou bien il ne l’a pas et les clients doivent alors le fuir au plus vite. Car pourquoi 92 % ? Quel est le delta de fichiers non récupérable ?

Tout cela ne semble guère sérieux et démontre si le besoin en était qu’il faut toujours appliquer 2 règles dans ce domaine :

  • se dire que les systèmes informatiques ont plus pour vocation de tomber en panne que de « tomber en marche »
  • que la meilleure attitude à avoir vis-à-vis d’un prestataire aussi central que GitLab, c’est la paranoïa. Ne jamais être satisfait des procédures mises en œuvre et s’attendre à ce qu’elles aient des failles. La peur n’éloigne pas le danger, mais elle permet de ne pas l’oublier.