Si je devais investir... 11 commentaires

Posté par Cedric, le 15/02/2009 - Business 2.0

T_cbc2ac8539452d2e82debb033f7a2c3fRécemment, Stéphane a publié un apercu des sociétés dans lesquelles il investirait. Je vais suivre son idée et sa suggestion, mais en essayant de me focaliser sur les spécificités qui font pour moi d'un projet qu'il peut être excitant et, bien sûr, rapidement rentable.

L'aspect humain

Assurer le meilleur retour sur investissement, c'est s'assurer que l'entreprise satisfait le maximum de critères garantissant la qualité du projet, ainsi que la solidité de l'équipe. Voici quelques pistes que j'étudierais, avant même de m'intéresser au produit:

- Le financement personnel - Les investisseurs mettent-ils l'argent de leur poche où s'agit-il exclusivement de "friends&family money"? Si l'argent des proches peut être un bon complément à une mise de fonds personnelle, il est difficile d'avoir la même implication viscérale lorsque 100% de l'argent provient d'un riche héritier en quête d'excitation entrepreneuriale.

- La complémentarité de l'équipe: Un grand classique, mais tellement important. Deux ingénieurs particulièrement brillants techniquement sont capables de sortir le meilleur produit jamais conçu, mais il n'est pas dit qu'ils sachent le marketer et le monétiser de la meilleure manière. En général, j'éviterais également les équipes trop nombreuses (pas plus de deux associés, pour garantir une prise de décision rapide et une moindre probabilité de conflits), je privilégierais les associations avec un leader établi (cela évite les goulets d'étranglement décisionnels et clarifie les choses dès le jour un),  et bien sûr, je choisirais le projet sur le profil des entrepreneurs et leur capacité démontrée à innover, à penser toujours une étape plus loin, à être multittâche et rigoureux, à faire avec application une tâche non appréciée (un commercial de nature qui s'applique avec sérieux à tenir sa comptabilité à jour), et bien sûr, avec une personnalité persévérante ET un savoir-vivre. Les bourreaux de travail ayant à mon sens moins de chances d'y arriver que les gens qui aiment leur travail, mais passeront toujours en premier plan leur famille et leurs passions.

L'entrepreneuriat n'est pas un 100 mètres, mais un marathon.

L'aspect produit


- Le secteur d'activité: plus le marché potentiel est énorme, moins l'entreprise aura besoin d'être grosse pour parvenir à gagner de l'argent.

- Le caractère entraînant du produit: sans forcément être le premier sur le marché, il faut démontrer qu'il existe une innovation significative qui garantira pendant plusieurs mois / années que les visiteurs se dirigeront naturellement vers ce service en particulier, et qu'ils y resteront. Généralement, cela consiste à faciliter largement l'entrée sur le site (penser à facebook), et à rendre pénible pour l'utilisateur le fait de le quitter (penser à facebook).

- Ce dernier point est d'autant plus vrai lorsqu'on a une cible professionnelle. Proposer un produit à forte valeur ajoutée permettant de faire des économies (pensons à une techno innovante qui permet de flexibiliser son entreprise et de réduire ses coûts... le cloud computing!) permet de "locker" ses clients pro rapidement, et lorsque vous bâtissez une architecture sur un tel service, il est très compliqué d'en sortir, soit autant de revenus réguliers pour vous.

- Avoir un public restrictif: je préfère financer un site pour les passionnés de tarot qu'un site de covoiturage. Plus la cible est difficile à cerner et se perd dans la globalité (un covoituré pouvant respectivement être passionné d'arts martiaux, proxénète ou chauffeur de limousine, voire les trois à la fois), plus il est difficile de vendre de l'espace publicitaire. L'exception pouvant être d'avoir un service payant, exception soumise au cas où il n'existe pas déjà un service équivalent gratuit.

- Avoir une technologie évolutive: Si j'investis dans un produit à dominante technologique, je veux miser sur une évolution forte du produit, seul facteur garantissant le maintiens d'une position de leader sur un marché. La technologie devra donc être facilement évolutive. Ainsi, un site fait avec Django en Python aura sa préférence sur du "spaghetti code" PHP 4 que seul le développeur stagiaire qui en est à la base serait capable de comprendre. Accessoirement, plus le code est clair et bien pensé, plus il est facile de le maintenir et étendre avec un faible nombre d'ingénieurs, donc moins le côté technologique coûte cher.

- Avoir un produit soigné. Inutile de développer ce point, puisque soit vous essayez de séduire des internautes en masse et dans ce cas, il faut soigner l'apparence, soit vous cherchez à vendre des produits / services, et il faut être clair et rassurant. Il faut donc une application soignée et compréhensible.

Des exemples?


Un marché pérènne (quoique, en ce moment..)  ET une technologie évolutive (symfony) ET une équipe extrêmement qualifiée ET une interface claire: Drimki

 

Une interface claire ET une technologique évolutive ET une cible restreinte avec un traffic de masse: Stackoverflow

 

Une innovation de rupture ET un service adressé aux professionnels ET une interface claire largement documenté: l'hébergeur Slicehost, à mi chemin entre de l'hosting semi-dédié et du cloud computing, avec une interface étonnamment simple. (ok, ce service a déjà été racheté par rackspace, mais quand même)

Une variante de ce dernier exemple avec RightScale qui cumule un service très pointu techniquement, une interface claire, un management compétent et un certain talent pour la communication et le marketing produit (lire leur blog).

Ce n'est là qu'un aperçu, je n'ai malheureusement plus assez de temps pour effectuer une veille régulière des startups qui se créent, mais les points évoqués ci-dessus (liste non-exhaustive évidemment) me paraissent garantir certains atouts pour les projets innovants qui apparaissent régulièrement dans nos flux RSS.

Et vous, dans quelles startup investiriez vous? Pensez-vous qu'il existe d'autres critères de réussite?

LinkedIn le trompeur 24 commentaires

Posté par Cedric, le 04/02/2009 - Marketing OnLine

T_bc72bf560eb7de716393f42eb2874d89En me balandant sur LinkedIn (portail social de connexions professionelles), je m'amuse souvent à lire les recommandations que s'envoient les gens de mon réseau. J'ai remarqué que, bizarrement, les gens les plus compétents avec qui j'ai eu l'honneur de travailler ont rarement une recommandation, ou alors en ont, mais en nombre assez restreint.

A l'inverse, j'ai trouvé beaucoup de gens sur LinkedIn que je qualifierais poliment de non-recommandables, disposant d'une dizaine, vingtaine, et même cinquantaine de recommandations.

C'est pour moi le signe d'une limite naturelle de ce système pourtant très à la mode: dans la mesure où nous sommes avant tout des humains, la politesse prédomine dans nos relations aux autres. Or, quand quelqu'un vous recommande (même si c'est une recommandation dont vous vous seriez bien passés), vous vous sentez obligés d'accepter sa demande de recommandation qui généralement suit dans les 48h. Ainsi, un élément qui passerait ses journées à recommander tout le monde maximiserait-il ses chances d'obtenir un nombre significatif de recommandations.

Le travailleur sérieux ne faisant que peu de vagues, et brillant souvent par sa discrétion, évite lui de demander à ses ex-collègues de dire publiquement à quel point il est génial, en se disant que s'ils le pensaient vraiment, il n'aurait peut être pas à leur demander.

Il y a du chemin à faire... 12 commentaires

Posté par Cedric, le 09/01/2009 - Business 2.0

Difficile de concurrencer des pays qui ont compris il y a déja 10 ans que les nouvelles technologies étaient un vecteur inespéré de croissance, quand on est dirigés par ca:

 

Via Rémi

Jobeet: Une vision convaincante 11 commentaires

Posté par Cedric, le 21/12/2008 - Technologie

T_bf7b2130de16cc7a4649c0e36ece40dfJobeet est un tutorial en 24 parties, destiné à couvrir l'ensemble des fonctions offertes par le framework symfony dans le contexte de réalisation d'un projet réel. Alors que la série touche à sa fin, on peut faire quelques observations:

#1 L'ordre des cours

L'équipe symfony a choisi de partir du cahier des charges (sous formes de stories, respectant les principes de l'XP), pour ouvrir les hostilités par le design, juste après la conception du modèle de données, avant de s'attaquer en profondeur à la couche métier.

C'est précisément l'ordre par lequel nous avons également eu le moins de surprises. Juste après la conception de données, nous nous attardons même sur le conception visuelle de l'ensemble des parties où l'utilisateur peut entrer des données. Généralement, donc, le back office. En plus du design des formulaires (très utile pour repasser ensuite aux formulaires objets, faire les bons empilements de formulaires et développer les bons widgets), on peut également designer les différentes listes proposées à l'administrateur, ainsi que les interactions qu'il devrait être en mesure de faire à partir de là (et les implémenter basiquement, y compris l'éventuelle couche javascript).

Il s'agit en fait d'un bon moyen pour se rendre compte des éventuelles incohérences de conception, puisqu'en partant de toutes les possibilités d'entrées de données, il est facile d'adapter le modèle de données au mieux, l'affichage en front n'étant très souvent qu'une simple exploitation de données entrées par ailleurs (ou alors, si ce n'est pas le cas, il convient dinclure ces interactions utilisateurs en front dans ce prototypage graphique du début). Commencer par l'aspect visuel permet aussi de rapidement traduire vos scénarii d'utilisation en modules, actions, et routes correspondantes.

#2 L'importance des plugins

Nous avons beaucoup aimé le retour appuyé sur l'utilité des plugins. En effet, les plugins ne sont pas uniquement des packages publics prets à l'emploi. Ils sont aussi peut être le meilleur moyen de développer la véritable intelligence de votre projet. En effet, leur réutilisation est extrêmement simple, et se résume souvent à copier/coller un répertoire, qui lui reprend l'ensemble de votre travail.

Ainsi, dans les traitements de la couche modèle que nous faisons, nous travaillons par itérations succsessives:

1/ définition du comportement souhaité (exemple, un modèle Article doit etre taggé par un modèle Tag)

2/ qualification selon le critère "besoin ponctuel" ou "fonctionnalité réutilisable". Si la fonctionnalité doit être réutilisée, soit sur un autre modèle du même projet (ex: modèle Video), soit sur un autre projet, nous pensons "plugin".

3/ Comme nous travaillons désormais uniquement sur Doctrine, nous avons le bonheur d'utiliser très régulièrement les Templates, natifs à l'ORM. Pour chaque template que nous créons, nous créons un plugin correspondant.

4/ Si des interactions utilisateurs sont propres à cette fonctionnalité, nous les ajoutons au plugin. Par exemple dans notre cas, nous pouvons y intégrer une interface d'administration pour voir la liste des tags et en supprimer, ou encore un widget spécial qui étend une fonctionnalité jQuery qui va puiser dans notre liste de tags pour auto-alimenter un champs text avec suggestions AJAX (qui lui même pourrait étendre ce widget déja existant).

Ainsi, l'application pure de notre système se résume à définir le comportement dans le modèle de données (actAs: Taggable), puis de définir notre nouveau widget dans notre formulaire (sfForm::setWidget('field' => myWidgetFormInputWhatever)). En bref, une fois que le plugin est développé, deux minutes de travail réutilisables sur tous nos modèles.

#3 L'ouverture sur le monde

Le move stratégique le plus intéressant de cette série de tutoriaux est d'avoir inscrit clairement symfony non comme une solution s'opposant aux autres offres du marché, mais comme une solution complémentaire, et en particulier un produit complémentaire du framework Zend.

C'est également une pratique que nous apprécions. En effet, de si nombreuses librairies ayant été développées pour Zend, qu'il serait contraire au principe DRY de vouloir réinventer la roue. De plus, symfony permet d'intégrer facilement n'importe quelle librairie externe. Zend_Rest, Zend_Gdata, Zend_Amf, Zend_Search_Lucene, et bien d'autres encore sont des librairies magnifiques tant elles vous font gagner du temps de développement.

En bref, ces tutoriaux nous ont fait découvrir le symfony que nous pratiquons et que nous aimons: une plateforme complète et fiable qui s'intègre avec toute l'intelligence créée par ailleurs, et qu'on peut vraiment développer de manière modulaire et incrémentale en réutilisant systématiquement chaque entité développée.

C'est en programmant de cette manière (avec des tests systématiques et complets) que l'ont peut beaucoup gagner en productivité, à mesure que l'expérience s'accumule.

Google Maps x Maroc 19 commentaires

Posté par Cedric, le 16/12/2008 - Technologie

Je suis content que Google Maps ait fini par couvrir le Maroc, où nous avons un bureau (à Rabat). En revanche côté précision, ce n'est pas encore tout à fait ca:

L'avenue de France semble allègrement empiéter sur les habitations des pauvres Rabati. Je vous rassure, dans la réalité, cela se passe très bien et elle est située bien sûr, au niveau de la grosse avenue juste au dessus sur la carte. Pareil pour l'avenue Oumeir, perpendiculaire à l'avenue de France. C'est en fait la grosse artère située à la droite de l'image.

En bref, méfiez vous si vous utilisez votre iPhone comme GPS au Maroc, car si vous avez déja la chance de trouver les noms des rues affichés (très rare), vous risquez quand même de vous perdre... à cause de Google!