Des liens en vrac concernant les start-ups

J’imagine que ça concernerait plutôt Stéphane Lee, mais je suis tombé récement sur quelques liens assez intéressants concernant les bonnes pratiques de gestion des start-ups. D’abord avec l’exemple à mon avis le plus éclatant (Google), et ses pratiques de recrutement. Ensuite avec quelques liens envoyés par Lars (qui doit savoir de quoi il parle, puisqu’il est justement dans le cas du type qui monte sa boîte). Et enfin les généricologues dans leur ensemble avec le score gbat et quelques commentaires intéressants.Je sais que je devrais relire tout éa attentivement pour en tirer la substantifique moëlle, mais là, désolé, j’ai pas trop le temps.

Formidable monde de tags !

Sans le savoir, {Stéphane Lee} a créé, sur son blog, une plateforme de blogs verticaux absolument géniale ! J’en ai d’ailleurs profité pour me créer mon journal de l’actualité de l’iBook, puisque je rêve de m’en acheter un. Mais, force m’est de le reconnaître, Stéphane, il manque à ces blogs générés une gestion éditoriale. C’est-à-dire la possibilité à partir d’une interface de publication de créer une revue de presse un peu plus intelligente, typiquement en enlevant toutes les choses inutiles qu’on peut recevoir comme par exemple ça (affiché sur ma page sur l’iBook), il faut le faire. Et là, tu le tiens, ton buisness model à pas cher : si il est difficile de vendre une vue non éditée de l’actualité d’un tag, construire, au-dessus, un contenu éditorial peut permettre de générer des recettes publicitaires, à la manière du blog auto, par exemple.

Tiens tiens …

Après mon petit article sur {L’ouvre-boîte}, je m’en doutais un peu (puisque je suis tombé sur sa version alpha). Il semble donc certain désormais que {Stéphane Lee} se soit lancé dans un projet ambitieux et intelligent de folksonomie à la française. Bravo Stéphane ! Et bon courage pour les corrections de bugs qui vont te tomber dessus ! Mais surtout, comme Stéphane est nettement plus malin que moi, la communication sur son outil est bien mieux organisée que la mienne à propos de {Boo.km.arcs} (d’ailleurs, je m’y remets cet après-midi).

Super gadget !

Dans le genre ça sert à rien, mais c’est génial, voici une petite application web basée sur {36trucs} et créant à partir de trucs communs un beau réseau de proximités. Et on y constate (encore heureux), que {Stéphane Lee} et moi partageons au moins un truc commun …Bref, c’est franchement bien fait, et ça m’amuse pas mal de l’utiliser pour constater qui sont les gens dont je suis proche. Je me demande si {43things} fournit la méme chose … Peut-étre est-ce le début de l’ére 36trucs ! Tant mieux pour son créateur.

Stéphane s’y remet ?

J’apprends à l’instant que Stéphane se remet à développer. Courage, on est avec toi ! Et si je peux répondre à la moindre de tes questions, n’héiste pas. Histoire de démontrer que le développeur est avant tout un pinailleur, il y a quand même une ou deux phrases qui me dérangent :

Maintenant, on parle de Java, de C#, de Perl, Python, PHP et Ruby. Je vois que ça n’a pas changé, toujours pas de standardisation sur un langage. NDR : Et si XML/XSLT les unifiait tous ?

Dans le tas, il y a quand même des horreurs. Pour ma part, j’ai décidé de me concentrer sur {Java}, {Ruby}, et tous les langages du web. Là où je ne suis pas d’accord, c’est à propos de la standardisation. Il y a actuellement une évolution des pensées pour aller de l’OOP vers la LOP. La différence ? Elle tient simplement au fait que le langage utilisé n’est pas simplement du Java, ou du C#, mais un langage à la sémantique spécifiquement adaptée au besoin. Et, dans ce domaine, le langage en pointe est le Ruby. C’est ce qui permet notamment aux applications Rails d’être si compactes : elles ne sont pas codées en Ruby, mais en Rails, qui est un langage étendant le Ruby pour s’adapter aux problèmes des applications web utilisant un SGBD (comme le montre par exemple cet article). Et là, Stéphane, ta standardisation sur un langage disparaît rapidement, pour être remplacée par l’adaptation à un problème, nettement plus efficace en termes de temps de codage.

Quant à XML/XSLT, pour m’en être déja servi (pour information, toute la partie statique de mon site, c’est-à-dire le reste accessible , est une application XML (Docbook)/XSLT/PHP, d’une complexité plus que respectable , eu égard à la complexité du problème), je peux te dire que c’est franchement une usine à gaz, nettement moins abordable que les langages susnommés.

Et puis, gueuler sur un ordinateur, c’est pas vraiment le truc le plus social qu’on peut faire.

C’est vrai, mais une spécification n’est pas un programme, et le code est tout ce que l’utilisateur voit.

Rénovons le recrutement en ligne !

Suite à un billet de l’ouvre-boîte, et pour faire avancer le Casimir, voici mes quelques idées. Comme d’habitude, et peut-être contrairement à l’esprit de prototype si chère dans {L’ouvre-boîte}, j’arrive avec mes gros sabots et mes idées toutes faites. Toutefois, coup de bol (ou pas), ayant changé de nombreuses fois d’employeur, je connais assez bien, en tant qu’utilisateur, les différentes plateformes de RH en ligne (ou tout au moins les essentielles que sont, dans mon domaine, l’APEC, Monster, et quelques autres moins évidents). Voici donc quelques besoins qui me semblent essentiels :

  • Un flux RSS pour chaque recherche que je lance. Bien sûr, Monster fournit une alerte par mail, mais c’est peut-être moins tendance, et surtout moins aggrégeable.
  • Une plus grande facilité de saisie. A chaque fois, saisir un CV coûte une bonne demi-heure de travail, à s’interroger follement sur la pertinence ou non de tel champ. J’ai maintenant tendance à penser que le bon CV n’existe pas. Pour expliquer ça, je vais prendre un exemple tiré de mon expérience personnelle. Un conseil en recrutement prend contact avec une PME qui souhaite recruter un développeur Java plutôt senior, ayant de bonnes connaissances dans un domaine fonctionnel (par exemple, le pilotage de process industriels), mais, surtout, capable de comprendre les implications d’une application conçue à partir d’un assistant visuel à base de graphes. Sur le CV du candidat, la seule chose se rapprochant est la participation à une startup très orientée maths et stats, avec notamment la conception d’une plateforme d’application. Avant que le candidat (moi, dans cet exemple) arrive jusqu’au chef de service R&D, il devra passer un entretien chez le conseil en recrutement, puis dans la boîte avec la responsable RH (que je salue au passage) avant de rencontrer son futur chef (que je salue également). Pourquoi toutes ces étapes ? A cause d’une ridicule limitation à une page pour le CV. A mon sens, le document que le candidat doit envoyer doit pouvoir toutes les informations qu’il juge utiles, exploitées de manière automatique.
  • Des tags partout, des tags sur tout. Ils sont nécessaires pour associer un besoin d’entreprise avec les candidats y correspondant, mais aussi pour permettre aux candidats de décrire leur expérience de manière claire. Malheureusement, afin de les rendre utilisables, leur association doit être particulièrement réfléchie, comme elle l’est justement dans le CV du candidat, où, en théorie, chaque mot est choisi. On peut donc considérer ce CV comme un catalogue de tags définissant ses compétences, ambitions et possibilités pour les employeurs potentiels.
  • Un format standard non microsoft. Il existe sur Internet au moins un format XML censé décrire un CV : XMLResume. Permettre l’export dans ce format faciliterait forcément la présentation des candidats, car on distinguerait la forme (éventuellement définie par diverses feuilles de style XSL du site, et même éventuellement modifiables par les candidats par le biais d’une bibliothèque de présentation partagée) du fond, défini par chaque candidat (tous les prestataires ou presque ont eu un jour la surprise de découvrir qu’ils avaient été présentés au client avec un CV bidon).

Notez bien que ce sont là des besoins de candidats, forts différents des besoins de recruteurs, pour lesquels l’interface de recherche et de text-mining sera beaucoup plus essentielle.

Applications des folksonomies

Suite à un trés long et encore plus intéressant article de {L’ouvre-boîte}, voici mes commentaires.

En avant-propos, une représentation graphique d’un espace de tags del.icio.us par Alf Eaton.

J’aime bien cette exploitation des tags delicious, mais je lui préfére cependant celle-ci. Pour aller plus loin, la visualisation simple d’un graphe de tags delicious me paraît assez peu pertinente. J’aurais tendance à lui préférer une représentation hyperbolique (qui s’apparente plutét dans ce document à un Fish Eye), qui permet d’avoir les points essentiels nettement plus visibles.

Et quelques remarques :- La représentation / exploration graphique (recherche, métadonnées) est une nécessité soulignée dans de nombreux billets sur Explorations et sur l’ouvre-boîte.

Et assez évidente., même si delicious permet de lister les liens associés à un ou plusieurs tags (par le biais, par exemple, d’un lien http://del.icio.us/tag/freeware+windows).

– Le graphique d’Alf Eaton est basé sur l’ancêtre (sic) TouchGraph, qui avait déjé proposé un GoogleBrowser aux fonctionnalités proches de celles de Kartoo, et aussi un LivejournalBrowser, une intégration avec une encyclopédie, un WikiBrowser, etc. (allez voir !). Vous pouvez aussi retrouver Touch Graph sur SourceForge. Il y a une littérature abondante sur les représentations visuelles, et de nombreux projets [1] dont par ex. prefuse (Java), ou encore FlickrGraph rçalisé en Flash.

Donc une utilisation efficace de Java pour produire autre chose que des pages à la noix ! Formidable ! (c’est le développeur Java qui parle).

– Alf a aussi rçalisé une cartographie des utilisateurs del.icio.us (« users as defined by their inbox subscription lists »). Bref, vive les API pour construire des Web Services …

Il existe aussi, parmi les innombrables outils delicious, un site permettant d’afficher les gens dont on est proche car taggant de manière proche les mêmes sites.

Et si cela ne suffit pas 🙂 pour donner des idées aux membres de l’ouvre-boîte pour améliorer blogs, wikis, logos-puces, to-do lists, recommandations, sites sociaux, (etc.)… allez, une petite citation extraite de LivejournalBrowser :The Touch Graph Live Journal Browser displays users as nodes connected by edges indicating friendship. Above the users float their mutually shared interests. Moving the mouse over an interest highlights the users that share that interest, and moving a mouse over a user highlights the friends and interests of that user. By examining at the interests above and between clusters one can see the subjects that bring together individuals and communities.

Ca ressemble d’assez prés à un projet de navigateur FOAF, permettant donc de se promener dans un réseau social, pour peu que les gens publient leur FOAF.

Une vraie soupe de tags , c’est le risque que soulignent de nombreux commentateurs, dont Stéphane Le Solliec dans cet article. « Oui, sauf qu’au final, c’est ça donne un gros bordel avec des tags, des catégories, des mots-clés dans tous les sens, … rien n’est inter-opérable, et l’on reste dans un univers plat, où si je cherche Indochine, j’aurais autant de réponses concernant le groupe de rock que le pays ».

Ce qui n’est pas interopérable, ce sont les web-services d’exploitation. Rien n’empêche une bande de courageux développeurs d’écrire la glue permettant, via une interface unifiée, d’accéder, à la delicious, à des liens vers tous les outils connaissant tel ou tel tag, avec même la mise en relation. Bref, le vrai moteur de tags.

Par exemple, on pourrait utiliser des tags en deux parties. Cette idée a été exprimée de nombreuses fois. Par ex. sur wixonomy on la met en action, et Stéphane Le Solliec la décrit ainsi : « (exemples 🙂 groupe:indochine et pays:indochine, groupe:Frantz Ferdinand et personne:Frantz Ferdinand, (…) Avec ces tags en deux morceaux, cela donne la possibilité de faire des listings genre listing de tous les groupes, listing de toutes les personnes, listing de toutes les villes ».

Jusqu’au jour où on constatera qu’il faut un troisième champ, pour une raison X ou Y. Il y a lé une espèce de mauvaise pratique, à mon sens, même si, fondamentalement, le concept de folksonomie implique l’adaptation à l’utilisateur. Pour ma part, pour distinguer les duplicats, je rajoute des tags. Par exemple, une page sur le groupe sera taggée « musique indochine » et le site touristique du pays « tourisme asie ».

Mais on peut faire mieux que des listes … On peut désambiguiser. On peut rechercher des significations univoques (autrement dit, à partir des folksonomies, personnaliser et partager des taxonomies).

Il y a là un point intéressant : on ne parle ici « que » de tags. Nous oublions les tous premiers fournisseurs de données et de meta-données : les pages web taggées. Qu’il s’agisse de liens delicious, d’actions 36trucs, ou d’autres choses (je ne suis pas trop au fait des autres ouvertures de boîtes), il y a toujours, quelque part, une donnée à laquelle le tag se réfère. Pourquoi ne pas s’en servir ?

Imaginez un graphe dont les noeuds soient des vocables (tags). Les arêtes reliant ces noeuds sont des relations entre les vocables (tags). En première analyse, il n’est pas nécessaire de caractériser (par ex. : égalité, inclusion, etc.) ces relations.

En seconde non plus. Si on caractérise ces relations, on va passer d’un type de géométrie relativement utilisable à un autre nettement plus complexe.

où et quand opérer des renforcements ? Exemple d’un site de signets partagés Cela peut être fait lors de l’utilisation d’un bookmarklet. L’interface demanderait quel(s) tag(s) utiliser, interrogerait ensuite le site de signets, puis présenterait les tags liés, et de quoi renforcer (ou ajouter) des liens.

Ou mieux, dans un navigateur qui pourrait par ce moyen proposer des sites au contenu proche de celui lu actuellement. une espèce de super-assistant qui dirait « ça aussi, ça peut vous intéresser », à la manière des références d’autres acheteurs qu’on peut trouver sur des sites marchands bien connus.

Cela peut aussi se faire (avec probablement un GUI plus riche et plus de features) sur le site de signets. Sur ce site, la description des signets comporterait une liste de tags avec leur poids, et si possible indiquerait quels tags sont insuffisamment liés (incitation aux visiteurs du site à travailler la question) Une page relative à un tag, ou à un utilisateur, présenterait une liste de tags « à lier » (sorte de to do) ainsi que les graphes des tags liés, etc.

Ca me donne bien envie d’essayer un truc en Javascript, ce bazar. Quoique produire un diagramme cross-browser en Javascript … c’est plutôt chaud !

ce qui permettrait d’ailleurs un couplage potentiel avec un service de to do partagés comme 36 trucs).

Le couplage de sites de ce type avec d’autres applications web me paraît indispensable. Si l’idée de partager ses trucs est intéressantes, se contenter de ça est à mon sens trop limité.

Il est évident qu’on approfondit considérablement les usages des folksonomies ou taxonomies si on peut conférer des attributs aux relations. La relation a::b peut, par exemple, être dotée de l’attribut « 

Encore une fois, si l’exploitation de concepts simplement proches est relativement aisée, l’utilisation de caractérisations de cette proximité rajoute un nombre de règles complètement ahurissant, mais fournit cependant une richesse fonctionnelle évidente.

Puisque le business model du search est bien établi (encore que …), un enrichissement des services de recherche (pertinence, matching) par des technologies de tags se fera dans le cadre de ces business models.

C’est exactement ce que fait Zniff.com, qui doit être la partie rentable de Spurl (qui n’a du coup pas à investir dans une technologie de crawling chère et parsant de nombreuses pages inutiles).

Ceci (puisque Seb Paquet le fait, l’ouvre-boîte aussi 🙂 ) est un appel à développeurs pour implémenter (Open Source, merci; que cela puisse librement être amélioré, intégré …) dans un Web Service l’exploration et le renforcement des chemins dans un graphe. En commençant par le plus simple : des relations « non caractérisées » (voir plus haut).

Qui héberge le projet ? Sourceforge (solution évidente) ? Et qui l’administre et le fait vivre ?

On pourrait commencer, en francophonie (ou européanité), par un GIE de maquettage de services innovants (On sait ce qu’il est advenu du GIE Airbus 🙂 ).

Société de R&D externalisée ?