L’équipe DuckDB est passée chez AWS le 1er septembre — j’ai relu nos 3 dépendances open source critiques, et 2 m’inquiètent

Panos Petropoulos

Expert développement web · 4 septembre 2026 · 13 min de lecture

AWS a annoncé fin août l’acquisition de DuckLabs, la société d’Amsterdam derrière DuckDB. L’opération s’est close le 31 août et l’équipe de trente personnes, cofondateurs compris, a rejoint AWS le 1er septembre 2026. Le projet, lui, reste sous licence MIT et gouverné par une fondation indépendante. Voilà pour les faits. Ce qu’ils devraient déclencher chez vous est un exercice d’une heure sur votre propre arbre de dépendances.

Le montage annoncé mérite d’être décrit précisément, parce qu’il n’est pas celui auquel on s’attend. AWS acquiert DuckLabs, la société. L’équipe rejoint AWS et continue de piloter la direction technique du projet. Mais DuckDB, DuckLake et Quack restent sous licence MIT, et la propriété du projet reste entre les mains de la DuckDB Foundation, entité indépendante créée bien avant l’opération.

Autrement dit : les personnes changent d’employeur, le code ne change pas de propriétaire. C’est une distinction que la plupart des rachats open source ne font pas, et elle vaut d’être notée avant de crier au loup.

Notre avis d’expert #1 — pourquoi ce montage est moins inquiétant que la moyenne

Le schéma habituel d’un rachat d’éditeur open source est le suivant : une société détient le dépôt, la marque, le nom de domaine et le droit de relicencier. Elle est rachetée, et l’acquéreur hérite mécaniquement de tout, y compris du droit de changer la licence des versions futures. Les épisodes de relicenciement des cinq dernières années ont tous suivi ce chemin.

Ici, la fondation préexistante casse ce chemin. Elle détient le projet ; l’acquisition porte sur la société de service. Cela ne rend rien impossible — une fondation a des statuts, un conseil, et ces choses évoluent — mais cela déplace la décision hors du bilan de l’acquéreur. C’est structurellement plus solide qu’une promesse de bonne conduite.

Ce que ce montage ne protège pas, en revanche, c’est le rythme. Une équipe salariée par un fournisseur de cloud priorise, sur le long terme, ce qui sert le produit de ce fournisseur. Ce n’est pas de la mauvaise foi, c’est de l’allocation de temps. Et ça ne se voit pas dans une licence.

L’exercice que l’annonce m’a fait faire : 3 dépendances, 2 problèmes

Une annonce comme celle-ci est surtout utile comme prétexte. J’ai pris nos trois dépendances les plus structurantes — celles dont le retrait imposerait une réécriture, pas un remplacement — et je les ai passées au même filtre.

La première est portée par une fondation reconnue, avec plusieurs dizaines de contributeurs actifs venant d’employeurs différents. Elle ne pose aucun problème : même un rachat de l’un de ses contributeurs majeurs ne changerait rien à sa trajectoire.

La deuxième est maintenue par une société de quinze personnes, sous licence permissive, avec un dépôt détenu par la société et non par une entité tierce. Une seule personne a fusionné 78 % des changements des six derniers mois. Ce n’est pas un projet communautaire ; c’est un produit gratuit. Le jour où cette société est rachetée, tout est sur la table, licence future comprise.

La troisième est le cas le plus commun et le plus mal évalué : un projet réellement communautaire, sain, actif — mais dont nous utilisons une fonctionnalité marginale que trois personnes maintiennent et que les responsables évoquent périodiquement de retirer. Le projet ne risque rien. Notre usage, si.

Notre avis d’expert #2 — le risque ne se mesure pas sur le projet, il se mesure sur votre usage

C’est l’erreur que je vois le plus souvent dans les revues de dépendances. On évalue la santé du projet — nombre d’étoiles, fréquence des versions, taille de la communauté — et on en déduit un niveau de risque. Or deux entreprises qui utilisent la même bibliothèque n’ont pas du tout la même exposition.

Ce qui détermine votre exposition, c’est la surface d’usage : combien d’appels distincts, quelles fonctionnalités, à quel point elles sont au cœur du produit, et surtout combien de semaines coûterait le remplacement. Un projet fragile utilisé pour une conversion de format en trois lignes est un risque nul. Un projet solide dont vous exploitez une extension confidentielle est un risque réel.

Les 4 questions du tri, dans l’ordre

Ce filtre prend environ vingt minutes par dépendance et ne demande aucun outil particulier. Il ne remplace pas une analyse de chaîne d’approvisionnement, il répond à une autre question : que se passe-t-il si l’entité qui porte ce projet change de mains ?

Les trois premières questions décrivent le projet. La quatrième décrit votre situation, et c’est elle qui doit trier la liste. Une dépendance à risque élevé mais remplaçable en trois jours passe après une dépendance à risque faible mais irremplaçable en moins de deux mois.

Notre avis d’expert #3 — ne forkez pas, chiffrez

La réaction que je vois le plus après ce genre d’annonce est le fork défensif. C’est presque toujours une erreur. Un fork crée une charge de maintenance permanente, immédiate et certaine, pour se prémunir d’un risque futur, hypothétique et rarement réalisé. Les forks défensifs créés dans la panique meurent en dix-huit mois, faute de mainteneur désigné.

La réponse proportionnée tient en trois gestes qui coûtent une demi-journée. Figer la version utilisée plutôt que suivre la branche principale. Archiver une copie du dépôt chez vous, y compris l’historique — c’est trivial et personne ne le fait. Et chiffrer le coût de remplacement en semaines-homme, en le documentant.

Ce dernier point est le seul qui compte vraiment. Le jour où un relicenciement ou un abandon survient, la décision se prend en urgence, et vous aurez besoin d’une estimation faite à froid. C’est aussi ce chiffre qui permet d’arbitrer aujourd’hui : au-delà d’un certain coût de remplacement, il devient rationnel de contribuer au projet, de financer un mainteneur ou de réduire volontairement sa surface d’usage.

Sur le volet chaîne d’approvisionnement — provenance des artefacts, signature, inventaire logiciel — les pratiques décrites par nos confrères en audit de sécurité se combinent bien avec cette approche de gouvernance, tandis que l’outillage d’automatisation permet de maintenir l’inventaire à jour sans revue manuelle trimestrielle. Si vous montez ou dimensionnez une équipe capable de porter ce travail, nos guides sur les outils métier sur mesure et sur le recours à des profils externes abordent la question en amont.

Ce qu’il faut retenir de l’opération

DuckDB va probablement très bien s’en sortir. Le code est sous MIT, la fondation est antérieure à l’opération, et l’équipe a publiquement annoncé continuer à piloter la direction technique. Les signaux à surveiller sur les prochains trimestres sont ailleurs : le délai de traitement des correctifs venant de contributeurs externes, l’apparition de fonctionnalités disponibles uniquement dans l’offre managée, et le renouvellement — ou non — du conseil de la fondation.

Aucun de ces signaux ne sera annoncé par un communiqué. Ils se lisent dans le dépôt, six à douze mois plus tard, et seulement si l’on a noté aujourd’hui à quoi ressemble la situation de départ.

Questions fréquentes