Elevator Pitch

AmauryCréation d'entrepriseLaissez un commentaire sur Elevator Pitch

Il existe un concept très intéressant, assez connu chez les américains : le « elevator pitch ».

L’idée est simple à comprendre. Imaginons que vous ayez créé une start-up, et que vous passiez du temps à un salon pour trouver un investisseur ; bizarrement, c’est après une longue journée infructueuse que vous allez croiser un important VC, dans l’ascenseur qui vous ramène à votre chambre d’hôtel. Ou encore, vous êtes un développeur ambitieux, et vous cherchez à présenter un projet personnel au big boss de votre compagnie ; et c’est près de la machine à café que vous tombez sur lui de manière imprévue. Ou vous souhaitez conclure un gros contrat avec un client important, mais vous êtes bloqué par son directeur commercial ; là encore, ce PDG fera un jour son footing dans le même parc que vous sans que vous l’ayez prévu.

Ce genre de situations ne semblent pas si inhabituelles qu’il n’y paraît. Une quantité non négligeable de contrats se signent de cette manière.

En quoi ce concept est-il intéressant ? Eh bien parce qu’il faut être préparé à ces situations. Dans ces conditions, le but est d’éveiller l’intérêt de l’interlocuteur, de l’accrocher pour qu’il ait envie d’en savoir plus. Et cela en quelques dizaines de secondes. Cela force à aller à l’essentiel.
Être enfermé 45 secondes avec quelqu’un oblige à synthétiser ses idées, à partager une vision large des choses (celle qui est intéressante !).

Tests unitaires et intégration continue

AmauryOrganisation d'équipe10 commentaires sur Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Pas d’intégrisme technologique

AmauryQuestions techniques2 commentaires sur Pas d’intégrisme technologique

J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.

On a tous entendu ce genre de réflexions :

  • « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
  • « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
  • « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
  • « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
  • « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
  • « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
  • « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.

On peut apporter des réponses intelligentes à toutes ces remarques :

  • Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
  • Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
  • Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
  • Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
  • La vraie question est plutôt « Pourquoi utiliser Windows ? ».
  • Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
  • Vous imaginez que Google tourne sur une seule machine ?

Faire un choix structurant

Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.

Prestation interne ou externe ?

AmauryQuestions techniquesLaissez un commentaire sur Prestation interne ou externe ?

Quand on doit choisir un outil informatique, l’une des questions que l’on doit se poser assez rapidement concerne le choix entre un outil interne à l’entreprise ou l’utilisation d’une prestation externe.

Quand je parle d’outil interne, je ne parle pas de développement réalisé en interne (même si ce cas existe bel et bien), mais des logiciels que l’on peut installer sur des machines propres à l’entreprise. Les prestations externes concernent les services qui sont disponibles à distance, souvent en SaaS (software as a service). Cela peut s’appliquer à un grand nombre de choses :

  • La gestion des emails. Votre entreprise doit-elle posséder son propre serveur SMTP, ou bien allez-vous passer par GMail/Hotmail/YahooMail ?
  • La gestion de document. Faut-il installer un serveur de fichiers interne, ou pouvez-vous vous reposer sur Google Doc/Zoho Docs ?
  • La gestion de projet. Est-il préférable d’utiliser une solution autonome, ou une plate-forme collaborative hébergée chez un prestataire ?

La prestation externe

L’utilisation d’un prestataire extérieur offre plusieurs aspects très pratiques :

  • Le service est disponible de partout (dans le cas de logiciels disponibles sur le Web). C’est très utile quand on a des collaborateurs disséminés géographiquement.
  • Le coût est limité. Les services d’email sont gratuits pour la plupart, et les offres logicielles payantes (gestion de projet, CRM, …) coûtent habituellement moins cher que la location d’un serveur.
  • La qualité du service est très bonne. Ces prestataires doivent gérer un très grand nombre d’utilisateurs, et mettent en place des architectures matérielles et logicielles prévues pour tenir la charge. Des équipes administrent ces services 24h/24, ce qui évite d’avoir à le faire soi-même.

L’installation interne

D’un autre côté, l’installation de logiciels en interne possède aussi de gros avantages :

Les erreurs à ne pas faire en entretien

AmauryVotre carrière27 commentaires sur Les erreurs à ne pas faire en entretien

Je vais réagir un peu à chaud, suite à quelques entretiens catastrophiques que j’ai fait passer dernièrement. Je vous ai déjà parlé des entretiens d’embauche, mais là je vais être très directif, presque lapidaire.

Soyez ponctuel

L’entretien d’embauche, c’est LE moment où il faut séduire le recruteur. Si vous êtes en retard le jour où vous devriez être au top, à quoi s’attendre au bout du quatrième mois de boulot sur un projet difficile ? Vous arriverez tous les jours après 11 heures du matin ?

Prenez soin de noter les coordonnées téléphoniques que vous pourrez appeler en cas de problème.

Apportez plusieurs copies de votre C.V.

Si vous arrivez les mains dans les poches, qu’est-ce que ça peut donner comme indice quant à votre envie de décrocher le poste ?

Par pitié, au moment où on vous demande « Vous avez une copie de votre C.V. ? », ne répondez surtout pas « Il est disponible sur Internet, vous pouvez l’imprimer » ! Cela revient à dire que c’est au recruteur de prendre le temps que vous n’avez pas voulu prendre vous-même.

Le plus « amusant », c’est que bien souvent le gros problème n’est pas pour le recruteur, mais pour le pauvre candidat qui se retrouve à tenter de présenter son parcours sans le support de son curriculum.

Connaissez-vous vous-même

En tant que candidat, vous devez fournir à votre interlocuteur des raisons de vouloir vous embaucher. Pour cela, vous allez lui parler de vos études et des entreprises où vous avez travaillé, mais ça ne l’intéressera pas. Ce qu’il veut, c’est que vous lui expliquiez en détail ce que vous savez faire, ce que vous avez fait, et ce que vous avez envie de faire.

Détaillez le travail que vous avez réalisé durant vos précédentes expériences professionnelles et/ou vos projets d’étude. Expliquez les problèmes que vous avez rencontrés, les solutions que vous avez appliquées, ce que vous avez appris. Dites si vous avez travaillé tout seul ou au sein d’une équipe, et alors expliquez votre rôle.

Il y a 2 situations qui sont difficilement supportables :

Réflexions sur la création d’entreprise

AmauryCréation d'entreprise5 commentaires sur Réflexions sur la création d’entreprise

Je vous en parlais récemment, j’ai participé la semaine dernière à une table ronde consacrée à la création d’entreprise. Les échanges étaient très intéressants, et cela m’a donné envie de vous résumer quelques idées sur le sujet.

Profiter de la jeunesse

Peut-être êtes-vous étudiant, ou fraîchement diplômé. Vous vous sentez l’âme d’un entrepreneur, mais vous avez peur de vous lancer dans une aventure un peu trop difficile, peur de vous rater. C’est assez logique de penser cela. On peut penser que plusieurs années de pratique sont nécessaires pour démarrer une entreprise, et que les risques augmentent de manière inconsidérée quand on crée une entreprise alors qu’on ne possède aucune expérience.

Mais en fait, c’est (presque) le contraire. L’élément le plus important, c’est que vous n’avez rien à perdre. Ceux qui ont créé une entreprise pendant leurs études (ou juste à la sortie de l’école) ne regrettent pas de l’avoir fait à ce moment-là, même lorsque cette entreprise a coulé rapidement. En gardant un mode de vie estudiantin, on n’a pas de gros besoins financiers. On n’a souvent pas encore de responsabilités familiales.

Au final, les risques pourraient difficilement être plus faibles. Dans le pire des cas, vous perdrez l’argent investi dans l’entreprise, qui peut être limité au minimum (voir plus bas). Réfléchissez bien : vous voulez créer une entreprise ; est-ce que ce sera plus facile quand vous aurez un prêt immobilier sur le dos et une famille à nourrir ?

Pas besoin de fonds

Les questions posées pendant la table ronde revenaient régulièrement sur le sujet des fonds nécessaires pour démarrer une activité. Et tous les créateurs d’entreprise présents étaient d’accord pour dire qu’il s’agit d’un faux problème.

Devoir composer avec des moyens limités impose d’être créatif et pragmatique. Il est important de garder à l’esprit que le but d’une entreprise est de générer des bénéfices, et lorsque l’on possède trop d’argent en banque on a le risque de vouloir créer pour la beauté du geste et non pour la finalité du business. C’est ce qui est arrivé à beaucoup de start-ups au début des années 2000. En ayant des ressources faibles, vous serez sûr de vous concentrer sur l’essentiel.

Sus aux emails

AmauryOrganisation d'équipeLaissez un commentaire sur Sus aux emails

Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.

Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.

Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.

Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :

  • Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
  • Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.

Table ronde sur la création d’entreprise le 04 mars

AmauryÉvénementsUn commentaire sur Table ronde sur la création d’entreprise le 04 mars

L’Epita, l’école d’ingénieur où j’ai fait mes études d’informatique, organise mercredi prochain (le 04 mars) une table ronde consacrée à la création d’entreprise. J’y serais, en compagnie de quatre autres anciens élèves de l’école, pour parler de mon expérience dans la création d’entreprise, les raisons qui m’y ont poussé, les problèmes rencontrés, etc.

Cette table ronde a lieu dans le cadre d’une semaine de projets pour les étudiants, mais est ouverte à tout public. Venez nombreux !

  • Mercredi 04 mars, de 18h00 à 20h00
  • Amphi 4, cours rue Voltaire, derrière le bâtiment principal de l’Epita

Toutes les informations pour s’y rendre

Les autres intervenants seront :

Le revendicateur

AmauryOrganisation d'équipeLaissez un commentaire sur Le revendicateur

Je vais m’attarder sur un profil très particulier de personnes, celles qui ont le chic pour réclamer et revendiquer toutes sortes de choses, sans arrêt et quelles que soient les circonstances.

Nous avons tous rencontré ce genre de personnes un jour ou l’autre. Alors que vous mettez en place le design logiciel d’une nouvelle application, un de vos développeurs va prendre une heure pour vous expliquer à quel point il est important que tout le monde utilise les mêmes outils de développement que lui, par soucis de cohésion. Ou pendant que vous réfléchissez à une plate-forme serveur, l’architecte logiciel va réclamer à cors et à cris l’utilisation de tel ou tel module, même s’il sait qu’ils n’ont pas été validés pour une utilisation en production. Ou alors, votre supérieur tente de mettre en place une mauvaise méthode de travail parce qu’il n’en connaît pas d’autre. Cela pourrait même être un stagiaire qui revendique le droit d’utiliser une partie de son temps de travail pour travailler sur des projets scolaires.

La première chose à comprendre, c’est que ces personnes ne viennent pas vous casser les pieds pour le plaisir (même si parfois ça y ressemble fortement). Intrinsèquement, les revendicateurs sont des angoissés. Ils n’ont pas trouvé d’autre moyen de diminuer leur anxiété qu’en la partageant avec les autres ; et malheureusement pour vous, ils sont tellement submergés par ces préoccupations qu’ils ne trouvent pas la bonne manière de formuler les choses. Au final, ils tentent d’imposer leurs vues, alors que ce dont ils ont besoin, c’est d’être rassurés quant au fait que leurs problèmes sont connus et pris en compte.

Je distingue quand même deux types de revendicateurs : ceux qui sont de bonne foi, et les égoïstes primaires.

Ce qu’il ne faut pas faire

La réaction naturelle face à un collaborateur qui vous harcèle de la sorte, c’est de l’ignorer. Mais en faisant cela, vous risquez surtout de le voir revenir à la charge, encore plus souvent et de manière encore plus véhémente. Si vous insistez dans cette démarche, vous allez au-devant de gros problèmes : un revendicateur n’accepte pas d’avoir une porte fermée devant lui, il l’enfonce. Certains d’ailleurs finissent par y prendre plaisir et cherchent inconsciemment de nouvelles portes à défoncer.