Virginie Clayssen a joué le jeu en me posant une question sur mon Google Moderator, je ne pouvais pas ne pas y répondre et ne pas jouer le jeu à mon tour.
La question est donc la suivante :

J’ai déjà parlé à plusieurs reprises des APIs mais le cas est ici plus concret. En fait, derrière la question formulée par Virginie, j’en entends immédiatement une autre qui la motive. Car s’agit il vraiment d’expliquer ce qu’est une API à un patron d’édition où bien plutôt de le convaincre de la nécessité d’initier une politique d’API ?

Certes, la compréhension entraîne l’adhésion pense-t-on généralement : et bien je crois que la plupart du temps c’est faux. Beaucoup d’adhésions et de décisions se font sur des quiproquos et des malentendus, tout comme beaucoup de compréhensions et de pédagogies peuvent provoquer des craintes et de l’immobilisme.
J’aurai donc tendance à répondre tout d’abord que pour chaque patron d’édition il y aura une stratégie particulière prenant en compte sa personnalité, la culture de sa maison, les caractéristiques de ses publications, mais aussi ses réseaux d’influence, etc. Là, c’est mon côté commercial qui parle, car je suis convaincu qu’on ne vend jamais la même chose à différents interlocuteurs, même s’il s’agit d’un même objet ou d’un même service, voire d’une même démarche s’il s’agit d’initier une politique particulière, et cela même si l’on reproduit exactement le même discours à chaque fois : car l’inconscient joue toujours son rôle, tapis dans les intersctices et la pénombre de notre langage.
Je ne cherche pas pour autant à me défiler en noyant la question sous un déluge de précautions et de réserves affirmant qu’il n’y a pas un discours mais des discours, ni un patron d’édition mais des patrons d’édition, etc. Mais je tiens toutefois à souligner qu’il y a des certainement des patrons d’édition avec qui il ne faut pas perdre de temps et pour lesquels il faut « donner du temps au temps », ou parfois simplement attendre qu’ils soient remplacés ou qu’ils partent à la retraite.
Ces remarques préliminaires étant faites, voilà comment je procèderais si je disposais de l’attention de mon interlocuteur (ou les dix commandements pour convaincre un patron d’édition de mettre en place des APIs) :

1. Je m’attacherais à rappeler que le métier d’une maison d’édition est double : il y a une composante éditoriale et industrielle (ou logistique)
2. La composante industrielle relève de sa condition de subsistance :  la production et la distribution des livres.
3. La composante éditoriale ne relève pas de sa subsistance mais de son existence : des choix sont fait, des politiques éditoriales sont menées, et la spécificité d’un catalogue et de ses collections en résulte.
4. J’insisterai sur le fait que ce dont peut souffrir le secteur de l’édition c’est la croyance que l’activité éditoriale est dépendante non pas d’une activité de production et de diffusion, mais de l’activité de production et de diffusion actuelle. (Universal Music croyait vendre de la musique mais ils se sont aperçus qu’ils vendaient en fait des galettes de polycarbonate avec de la musique dessus).
5. Je corrigerai immédiatement le tir en précisant que la question n’est pas de tirer un trait sur le livre en tant qu’objet, pas plus que sur la logique industrielle de l’édition existante.
6. L’enjeu est donc de porter les politiques éditoriales vers une logique de diffusion multicanal, réticulaire pour être plus exact,  qui déborde le sillon unique actuel de la chaîne de production : choix et validation validation des œuvres, mise en page, impression, production des livres et diffusion.
7. La clé de cette diffusion réticulaire ce sont les APIs en tant qu’interfaces d’accès aux données numériques de la maison d’édition.
8. Une API n’est pas une porte ouverte d’où les textes pourraient échapper au contrôle de la maison d’édition, bien au contraire. Une API est une interface qui permet de contrôler l’exposition et l’utilisation qui sont faites des données numériques de la maison : son catalogue aussi bien que ses oeuvres. Initier une politique d’APIs c’est d’abord vouloir garder le contrôle de ses données/
9. In fine, les APIs n’enlèvent rien au rôle et à la fonction d’une maison d’édition. Bien au contraire, c’est une invitation à mener une politique du numérique en réseau d’une maison d’édition afin de lui éviter de devenir endémique.
10. A noter que la partie logistique doit participer pleinement à cette politique car son système d’information en sera un des premiers clients, tout comme elle sera intéressée par les statistiques d’utilisation des APIs de la maison d’édition pour permettre une meilleure gestion de la production et des stocks de livres.

La question du fonctionnement technique d’une API n’est donc pas le problème qui doit intéresser dans un premier temps le « patron d’édition qui n’y connait rien ». Ce que doit représenter le terme API à ses yeux c’est , me semblet-t-il, que cela réclame que sa politique d’édition puisse s’incarner et se diffuser dans une granularité de questions beaucoup plus précises et concises qu’auparavant.
Mon sentiment, et je terminerai la-dessus, est qu’il ne faut pas chercher à convaincre le patron d’édition de mettre en place des APIs, mais lui indiquer que la mise en place des APIs requiert qu’un certain nombre de questions bien précises trouvent des réponses : à qui faut-il donner des clés d’accès aux données? y a t il un nombre de requêtes maximal par clé d’accès? quelles données sont accessibles ? quelles fonctions de manipulation des données sont offertes par les APIs ? quelles sont les données en lecture, en simple consultation, et celles qui pourront être écrites par des tiers? de quoi ont besoin les gens de la logistique pour mieux gérer la production? comment faciliter les échanges avec les libraires et les bibliothèques? etc. Toutes ces questions sont concrètes, et plus on se les pose plus on a de chance d’avancer sur la nécessité d’avoir une politique d’exposition réticulaire des données de la maison d’édition, c’est à dire de mettre en place des APIs.

Related posts:

1. Apple et le marché de l’édition électronique Avec la sortie présentie de sa tablette au premier trimestre...
2. Les données mises à nue L’exposition des données est l’un des trois éléments du code...
3. Potluck Dans les cartons du projet SIMILE, l’application Potluck va enrichir...

Le mail c’est ringard, les jeunes ne l’utilisent plus paraît-il. Dans l’entreprise, il donne lieu à des pratiques dont beaucoup se plaignent.

Mais voilà qu’avec la mise en avant des réseaux sociaux on se dit que le « social graph » tant recherché est finalement là, dans nos boîtes mail, constitué par l’ensemble des destinataires avec lesquels nous correspondons, avec des relations typées par les « objets » de chaque mail, enrichies des corps de messages.

Presque simultanément, deux grands acteurs du webmail, Yahoo et Google, se lancent dans ce que l’on pourrait appeler, à l’image de cet article de Saul Hansell, Inbox 2.0, des réseaux sociaux générés à partir de notre activité mail.

Avez-vous suivi les évolutions de Gmail récemment ? Coup sur coup Google à ouvert la compatibilité avec le protocole imap puis a proposé des « APIs » pour transférer les boites mail outlook vers Gmail.

L’email est notre identifiant premier. Aucune application web ne vous est ouverte sans email. La première chose que l’on vous demande c’est une adresse email valide pour confirmer votre existence réelle.
Les APIs d’accès aux services web que sont les comptes utilisateurs passent par le mail. Quoi de plus logique donc que la « API » company qu’est Google en fasse son fer de lance ?

Related posts:

1. L’implicite et l’explicite dans les réseaux sociaux On peut dégager deux tendances dans la constitution des réseaux...
2. Le Web Sémantique recrute ! Je cherche à recruter un consultant connaissant les normes du...
3. Livre sur les Réseaux Sociaux Je suis un des auteurs du livre sur les Réseaux...

L’exposition des données est l’un des trois éléments du code génétique du Web 2.0 (les deux autres étant la participation, et la simplicité).

Forcément, quand on expose ses données, il faut deux choses pour que çà tienne la route :

• la qualité et l’intérêt des données elles-mêmes.
• la qualité des APIs pour accéder à ces données.

Avec les normes du web sémantique, il n’y a plus d’APIs. La qualité des données passe par l’environnement de description des ressources que sont ces données.

Les données sont mises à nue, plus besoin d’APIs. C’est là que l’intérêt du jeu est décuplé : quand on n’a plus de contraintes dans la manière dont on peut utiliser les données elles-mêmes, il y toujours plus de plaisir.

Je me suis rendu compte que c’était précisément sur ce point que ceux qui ont un profil de développeur pouvaient buter dans leur compréhension du web sémantique.

Car çà peut faire bizarre de dire « pas d’API avec le web sémantique ! ». J’imagine qu’un développeur doit penser que c’est impossible, il doit forcément y avoir des API pour accéder aux données !

Des data sans API, c’est comme un visage sans bouche, çà ne peut rien dire !

C’est pourtant de çà dont il est question : un web of data est un web sans APIs, alors que les data on the web continuent d’avoir besoin d’APIs.

Peut-être faut-il illustrer tout ceci avec la fameuse API Open Social de Google. Parce que Google, çà a toujours été çà : à défaut d’être la » happy company« , c’est la « API Company« .

Google se battra toujours pour la liberté de l’accès aux données, et c’est bien normal puisqu’il est le passeur qui prend sa commission au passage. C’est un peu le robin des bois de Shrek.

Google ne veut pas des gated communities à la FaceBook, et nous non plus d’ailleurs. Il veut des conteneurs , plusieurs conteneurs, dont il assure l’interopérabilité et pour lesquels il garde la maîtrise des flux migratoires. C’est pour cela que les APIs sont les « DRM des données », le passage obligé.
Dit autrement, Google prône la liberté d’accès aux données, mais pas la liberté des données elles-mêmes. Il y a toujours un poste de garde, aussi beau et agéable soit-il.

Trois visions du web donc :

• Des réseaux privés, sortes de gated communities : c’est FaceBook s’il résiste à la démarche Open Social API.
• Une API ouverte, pas de gated communities, le web reste la plateforme : c’est Google. Bien sûr, l’API n’a rien de fondamentalement ouverte. Elle reste le DRM et la clé de l’accès aux données ; il n’y a pas de barrière, mais un chemin d’accès qui balise les pratiques et normalise l’accès aux données.
• plus d’API : c’est le web of data du web sémantique

Related posts:

1. Quand les métadonnées ont plus de valeur que les données Sous format numérique, les données ont tendance à avoir une...
2. MeetUp Semantic Web Ce jeudi 16 décembre 2010, à 17h, rendez-vous au MeetUp...
3. Prendre soin des données Sur le blog d’Atos Origin je reviens sur les enjeux...