Aaron Swartz et l'ouverture d'Internet : idéaux vs réalité des plateformes

Le problème : les idéaux d’un Internet ouvert rencontrent les incitations des plateformes

Quand on évoque Aaron Swartz et l’ouverture d’Internet, on pointe généralement une promesse simple : le savoir doit être facile à partager, facile à réutiliser et ne pas être enfermé derrière des barrières inutiles. Le web primitif faisait de cela une norme. Puis sont arrivées les grandes plateformes, qui ont changé les incitations.

Les plateformes ne sont pas automatiquement mauvaises. Beaucoup sont utiles, sûres et soignées. Mais elles grandissent en retenant l’attention, en collectant des données et en réduisant le turnover. L’ouverture peut entrer en conflit avec ces trois objectifs. Si les utilisateurs peuvent partir facilement, comparer les options ou réutiliser leurs données ailleurs, une plateforme peut perdre son levier.

Quelques termes, en langage simple :

• Ouverture : les gens peuvent accéder, réutiliser et construire sur ce que vous publiez, avec des règles claires.
• Plateforme : un service qui héberge votre travail et fixe les règles de stockage et de partage.
• API : une porte contrôlée qui permet au logiciel de communiquer avec un service (souvent avec des limites).
• Portabilité : vous pouvez déplacer vos données ou votre travail vers un autre outil sans repartir de zéro.
• Export : vous pouvez télécharger ce que vous avez créé dans des formats utilisables, pas seulement des captures d’écran ou des PDF.

Cette tension apparaît partout. Une entreprise peut se dire « ouverte », mais livrer une API coûteuse, limitée ou changeante sans prévenir. Ou elle peut permettre l’export, mais seulement dans un format qui perd des éléments clés comme les commentaires, les métadonnées, les relations ou l’historique.

Des personnes construisent de vraies vies et des entreprises sur ces systèmes. Quand les règles changent, elles peuvent perdre l’accès, le contexte et le contrôle. L’objectif moderne n’est pas de romantiser le passé, mais de concevoir des outils qui respectent les utilisateurs avec des API claires, des limites honnêtes et une vraie portabilité, y compris l’export du code source quand c’est pertinent (comme dans des outils de vibe‑coding tels que Koder.ai).

Ce que défendait Aaron Swartz, en termes simples

Aaron Swartz est souvent rappelé comme une voix pour un web ouvert où le savoir est plus facile à trouver, à utiliser et à reprendre. L’idée de base était simple : l’information qui aide les gens à apprendre et à participer à la société ne devrait pas être enfermée derrière des barrières techniques ou commerciales quand elle peut raisonnablement être partagée.

Il plaidait pour la liberté des utilisateurs en termes concrets. Si vous pouvez lire quelque chose, vous devriez pouvoir l’enregistrer, le citer, le rechercher et le déplacer vers des outils qui vous conviennent mieux. Cette vision soutient naturellement l’accès public à la recherche, la transparence des informations gouvernementales et des systèmes qui ne traitent pas la curiosité comme suspecte.

Les normes du web naissant confirmaient cela. Le web a grandi en reliant des pages entre elles, en citant de petits extraits avec attribution et en publiant dans des formats que beaucoup d’outils pouvaient lire. Des protocoles simples et des formats interopérables facilisaient la publication pour de nouveaux créateurs et l’émergence de services sans demander de permission.

L’ouverture a relevé le niveau pour tout le monde. Elle a facilité la découverte, aidé la diffusion de l’éducation et donné aux petites équipes une chance de concurrencer en se connectant à ce qui existait déjà plutôt qu’en tout reconstruisant à l’intérieur de silos privés.

Il est aussi utile de distinguer les idéaux moraux des règles juridiques. Swartz parlait de ce que l’Internet devrait être et pourquoi. La loi est différente : elle définit ce que vous pouvez faire aujourd’hui et quelles sont les sanctions. Le problème compliqué est qu’une restriction légale n’est pas toujours juste, mais la violer peut quand même causer de vrais dommages.

Une leçon pratique est de concevoir des systèmes qui réduisent les frictions pour les usages légitimes tout en traçant des limites claires pour les abus. Un étudiant qui télécharge des articles pour les lire hors ligne fait quelque chose de normal. Un robot qui copie une base de données entière pour la revendre est différent. De bonnes politiques et un bon design produit clarifient cette différence sans traiter chaque utilisateur comme une menace.

Comment les plateformes ont changé les incitations autour de l’information

La culture du web primitif considérait l’information comme un bien public : référencable, copiables et facile à reprendre. Avec la montée des plateformes, l’unité de valeur principale est passée des pages aux utilisateurs, et de la publication au maintien des personnes dans une seule application.

La plupart des grandes plateformes gagnent de l’argent de façons prévisibles : l’attention (publicité), les données (ciblage et insights) et le verrouillage (rendre coûteux le départ). Cela change le sens de « accès ». Quand le modèle dépend des visites répétées et d’un revenu prévisible, limiter la réutilisation peut ressembler à de la protection, pas à de l’hostilité.

Les paywalls, abonnements et licences sont généralement des choix commerciaux, pas des actes de méchant dans un dessin animé. Les rédacteurs, les serveurs, la protection contre la fraude et le support client coûtent de l’argent. La tension apparaît quand le même contenu a une importance culturelle, ou quand on attend que les normes du web ouvert s’appliquent partout.

Les conditions d’utilisation sont devenues une couche de contrôle à côté de la technologie. Même si quelque chose est techniquement accessible, les règles peuvent restreindre le scraping, les téléchargements en masse ou la redistribution. Cela peut protéger la vie privée et réduire les abus, mais aussi bloquer la recherche, l’archivage et les sauvegardes personnelles. C’est l’une des principales collisions entre les idéaux d’ouverture et les incitations des plateformes modernes.

La centralisation n’est pas que mauvaise. Elle apporte aussi des bénéfices réels sur lesquels beaucoup d’utilisateurs comptent : fiabilité, paiements et vérifications d’identité plus sûrs, réponses aux abus plus rapides, recherche et organisation cohérentes, et onboarding plus facile pour les non‑techniques.

Le problème n’est pas l’existence des plateformes. C’est que leurs incitations récompensent souvent le maintien des informations et des workflows enfermés, même quand les utilisateurs ont des raisons légitimes de déplacer, copier ou préserver ce qu’ils ont créé.

Les APIs : ouverture avec conditions

Une API, c’est comme une carte d’un restaurant. Elle vous dit ce que vous pouvez commander, comment le demander et ce que vous recevrez. Mais ce n’est pas la cuisine. Vous ne possédez pas les recettes, les ingrédients ni le bâtiment. Vous êtes un invité utilisant une porte avec des règles.

Les APIs sont parfois présentées comme la preuve qu’une plateforme est « ouverte ». Elles peuvent être une vraie avancée vers l’ouverture, mais elles clarifient aussi une chose : l’accès est accordé, pas inhérent.

De bonnes APIs permettent des usages pratiques dont les gens ont réellement besoin : connecter des outils existants, automatiser des tâches routinières, construire des interfaces d’accessibilité et partager l’accès en toute sécurité avec des jetons limités plutôt qu’avec des mots de passe.

Mais les APIs s’accompagnent souvent de conditions qui façonnent discrètement ce qui est possible. Limites de fréquence, endpoints manquants (certaines actions non disponibles), paliers payants (l’accès utile coûte), et changements soudains (fonctionnalités retirées ou règles modifiées) sont courants. Parfois, les conditions interdisent des catégories entières d’usage même si la technique le permettrait.

Le problème central est simple : une API est un accès avec permission, pas une propriété. Si votre travail vit sur une plateforme, l’API peut aider à déplacer des pièces, mais elle ne garantit pas que vous pouvez tout emporter. « Nous avons une API » ne devrait jamais clore la conversation sur l’ouverture.

Accès à l’information vs mauvaise utilisation : où la frontière devient floue

L’argument pour l’information ouverte est facile à apprécier : le savoir circule plus vite, l’éducation coûte moins cher et les petites équipes peuvent construire de nouveaux outils sur des bases partagées. La question plus difficile est ce qui se passe quand « accéder » devient copier à grande échelle.

Une façon utile de juger est d’évaluer l’intention et l’impact. Lire, rechercher, citer et indexer peuvent augmenter la valeur publique. L’extraction en masse qui reconditionne les mêmes matériaux pour la revente, surcharge un service ou contourne un paiement équitable est différent. Les deux peuvent utiliser la même méthode (un script, un appel API, un téléchargement), mais les résultats et le dommage peuvent être très éloignés.

La vie privée complique encore les choses, parce qu’une grande partie des « données » concerne des personnes, pas seulement des documents. Les bases peuvent inclure des emails, des profils, des positions ou des commentaires sensibles. Même si un enregistrement est techniquement accessible, cela ne signifie pas que les personnes impliquées ont donné un consentement significatif pour qu’il soit collecté, fusionné avec d’autres sources ou largement partagé.

Les institutions restreignent l’accès pour des raisons qui ne sont pas toujours cyniques. Elles peuvent couvrir des coûts d’hébergement et de personnel, honorer des ayants droit ou prévenir des abus comme le scraping qui submergerait des serveurs. Certaines restrictions protègent aussi les utilisateurs du profilage ou du ciblage.

Quand vous jugez une situation, un test d’arbitrage rapide aide :

• Qui bénéficierait si l’accès était ouvert, et comment ?
• Qui paie le coût (argent, vie privée, sécurité, indisponibilité) ?
• Le même objectif peut‑il être atteint avec moins de données, moins de fréquence ou plus de consentement ?
• Existe‑t‑il une voie claire de responsabilité en cas d’abus ?

Un étudiant qui télécharge un article pour étudier n’est pas la même chose qu’une entreprise qui extrait des millions d’articles pour vendre un archive concurrente. La méthode peut sembler similaire, mais les incitations et les dommages diffèrent.

Concevoir des outils qui respectent les utilisateurs : portabilité et export

La portabilité signifie qu’un utilisateur peut partir sans repartir de zéro. Il peut déplacer son travail, conserver son historique et continuer à utiliser ce qu’il a construit. Ce n’est pas pour pousser les gens dehors. C’est pour s’assurer qu’ils vous choisissent chaque jour.

L’exportabilité est le côté concret de cette promesse. Les utilisateurs peuvent emporter leurs données et, quand c’est pertinent, le code qui les produit, dans des formats qu’ils peuvent vraiment utiliser ailleurs. Une capture d’écran n’est pas un export. Une vue en lecture seule n’est pas un export. Un PDF est rarement suffisant si l’utilisateur doit continuer à construire.

C’est là que les idéaux d’ouverture rencontrent le design produit. Si un outil retient le travail de quelqu’un en otage, il apprend à ne pas lui faire confiance. Quand un produit rend le départ possible, la confiance augmente et les grands changements paraissent moins risqués parce qu’il existe une issue.

Un exemple concret : quelqu’un construit un petit portail client sur une plateforme de codage par chat. Des mois plus tard, son équipe doit l’exécuter dans un autre environnement pour des raisons de conformité. S’ils peuvent exporter le code source complet et les données de la base dans un format clair, la migration reste du travail, mais pas une catastrophe. Koder.ai, par exemple, prend en charge l’export du code source, ce qui constitue une base rendant la portabilité réelle.

Un export réel a quelques exigences non négociables. Il doit être complet (inclure relations et réglages signifiants), lisible (formats courants, pas des blobs mystérieux), documenté (un README simple) et testé (l’export fonctionne réellement). La réversibilité compte aussi : les utilisateurs doivent pouvoir récupérer d’anciennes versions, pas seulement télécharger une fois et espérer.

Quand on conçoit l’export dès le départ, on conçoit aussi des systèmes internes plus propres. Cela profite même aux utilisateurs qui ne partent jamais.

Étapes pour ajouter la portabilité à un produit

Si vous tenez à l’ouverture, la portabilité est l’endroit où l’idée devient concrète. Les gens doivent pouvoir partir sans perdre leur travail, et pouvoir revenir plus tard sans repartir de zéro.

Une manière pratique de l’implémenter sans transformer votre produit en chaos :

1. Décidez ce qu’un utilisateur peut emporter : enregistrements principaux plus le contexte qui leur donne du sens (fichiers, réglages, relations et historique partageable).
2. Choisissez des formats que les gens peuvent ouvrir : CSV pour les tableaux, JSON pour les données structurées, formats média standards pour les upload. Évitez les exports lisibles seulement par votre appli.
3. Utilisez des identifiants stables : les éléments ont des IDs qui ne changent pas pour que les imports ne créent pas de doublons.
4. Construisez l’import, pas seulement l’export : l’export aide à partir ; l’import aide à revenir ou migrer.
5. Expliquez ce qui est inclus : une note en langage clair qui indique ce que vous exportez, ce que vous n’exportez pas, et pourquoi.

Pour un constructeur basé sur le chat comme Koder.ai, « exporter » devrait signifier plus qu’un dossier de code zippé. Cela devrait inclure le code source, le modèle de données de l’app, les paramètres d’environnement (avec les secrets retirés) et des notes de migration pour qu’elle puisse fonctionner ailleurs. Si vous supportez les snapshots et le rollback, précisez ce qui reste à l’intérieur de la plateforme et ce qui peut être emporté.

La portabilité n’est pas seulement une fonctionnalité. C’est une promesse : les utilisateurs possèdent leur travail, et votre produit gagne leur fidélité en étant digne de confiance.

Erreurs fréquentes qui créent du verrouillage par accident

Beaucoup de verrouillages ne sont pas malveillants. Ils surviennent quand une équipe livre une portabilité « suffisante » et n’y revient jamais pour la compléter. De petits choix décident si les utilisateurs peuvent vraiment partir, auditer ou réutiliser ce qu’ils ont créé.

Quelques patterns courants :

• Contexte manquant : vous exportez des éléments mais pas les tags, commentaires, permissions, historique ou relations. Les données existent, mais elles perdent leur sens.
• Dumps inutilisables : un énorme fichier JSON sans schéma, sans horodatages et avec des IDs incohérents est « techniquement possible » mais pratiquement mort.
• APIs sans versionnage : renommer des champs ou changer les formes de réponses casse silencieusement des automatisations.
• Paywalls autour de la mobilité basique : facturer pour la commodité peut être raisonnable, mais les utilisateurs ont besoin d’un chemin clair pour récupérer leur travail.
• « Supprimer est facile, exporter est difficile » : un clic pour supprimer un compte, mais des jours de tickets et d’attente pour récupérer les données.

Un exemple simple : une équipe développe un tracker de projet. Les utilisateurs peuvent exporter des tâches, mais l’export omet les pièces jointes et les relations tâche→projet. Lors d’une migration, ils obtiennent des milliers de tâches orphelines sans contexte. C’est du verrouillage accidentel.

Pour éviter cela, traitez la portabilité comme une fonctionnalité produit avec des critères d’acceptation. Définissez ce que « complet » signifie (y compris les relations), documentez les formats et testez un vrai aller‑retour : exporter, ré‑importer et vérifier qu’on n’a rien perdu d’important. Les plateformes comme Koder.ai qui supportent l’export du code source et les snapshots fixent une attente utile : les utilisateurs doivent pouvoir prendre leur travail et le faire fonctionner ailleurs.