Bientôt la dernière séance de traduction ! Jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction framalang : tcit, Julius22, Sky, lamessen, goofy, peupleLà, merlin8282, lamessen, Jej, Alpha

Le Logiciel Libre dans le secteur public

Till Adam

Issu du milieu de la musique et des sciences humaines, Till Adam a passé pas loin des dix dernières années dans le monde de la programmation. Il travaille au sein de KDAB où il dirige plusieurs services, dont celui qui est en charge des logiciels libres. Till officie aussi au sein du conseil d’administration de Kolab Systems AG, une entreprise dont le modèle économique repose entièrement sur les logiciels libres. Il vit avec sa femme et sa fille à Berlin.

Introduction

J’imagine que comme de nombreux autres auteurs de cette compilation d’articles, j’ai commencé à contribuer au logiciel libre lorsque j’étais étudiant. J’avais décidé relativement tard dans ma vie de poursuivre un cursus en informatique (ayant échoué à devenir riche et célèbre en tant que musicien). Je m’attendais donc à être légèrement plus âgé que mes pairs en obtenant mon diplôme. J’ai donc pensé qu’il serait bénéfique d’apprendre par moi-même la programmation, qui ne m’était pas trop enseignée à l’école, afin de d’avoir plus d’atouts aux yeux de futurs employeurs, en dépit de mon âge. Après quelques incursions dans diverses petites communautés, j’ai finalement trouvé ma voie dans le projet KDE et j’ai commencé à travailler sur l’application de courriel.

Grâce aux personnes extrêmement serviables et douées techniquement que j’y ai rencontrées, j’ai pu apprendre rapidement et contribuer de façon significative au code, ce qui m’a entraîné de plus en plus dans leur réseau social, mais aussi vers le domaine fascinant des problèmes techniques liés à la gestion de données personnelles.

Lorsque KDAB, une entreprise remplie de gens qui utilisaient KDE, m’a demandé si, dans le cadre d’un stage étudiant, je voulais les aider sur la partie commerciale d’un projet en cours, j’ai bien sûr été ravi de pouvoir gagner ma vie et bidouiller le logiciel KDE en même temps. Au fil des ans, j’ai été témoin de l’adoption et de l’utilisation des architectures de gestion des données personnelles de KDE par le secteur public, particulièrement en Allemagne, où j’ai pu y assister personnellement à la croissance économique de KDAB dans ce secteur géographique. Alors que j’évoluais vers des postes plus orientés sur le management, vendre et livrer des services issus du logiciel libre comprenant des produits de KDE à de grandes organisations, en particulier dans le secteur public, a finalement fait partie de mon travail.

Il faut noter que la plupart du travail sur le projet qui a inspiré ce texte était généralement fait en collaboration avec d’autres entreprises du logiciel libre, à savoir glOcode, un spécialiste de la cryptographie qui se charge du maintien de GNUPG, et Intevation, une entreprise de conseil qui se concentre exclusivement sur le logiciel libre ainsi que ses défis stratégiques et opportunités. Mention spéciale à Bernhard Reiter, l’un des fondateurs d’Intevation, qui a joué un rôle clé lors de la vente et de la conduite de bon nombre de ces projets. Les quelques fragments de sagesse contenus dans ce texte sont probablement issus de son analyse et des nombreuses conversations que j’ai pu avoir avec lui au fil des ans.

Donc, si Bernhard et moi pouvions revenir dans le temps, quelles pourraient donc bien être les idées que nous partagerions avec nos « nous »  plus jeunes et plus naïfs ? Eh bien, il s’avère qu’elles commencent toutes par la lettre P.

Personnes

Telles que sont les choses aujourd’hui, il est toujours plus difficile pour les gens de terrain des technologies de l’information et pour les décideurs d’utiliser du logiciel libre que ça ne l’est d’utiliser les alternatives propriétaires. Même en Allemagne, où le logiciel libre a un soutien politique relativement fort, il est plus facile et plus sûr de suggérer l’utilisation de quelque chose qui est perçu comme un « standard de l’industrie » ou comme « ce que tous les autres font » ; en d’autres termes, des solutions propriétaires.

Celui qui propose une solution en logiciel libre fera probablement face à de l’opposition de la part de collègues moins aventureux (ou ayant moins de vision), à un examen minutieux des supérieurs, à de plus grandes attentes par rapport aux résultats et à une pression budgétaire irréaliste. Il faut donc un type particulier de personnes souhaitant prendre des risques personnels, potentiellement compromettre l’avancée de leur carrière et combattre dans une bataille presque perdue d’avance. Ceci est bien sûr vrai dans n’importe quelle organisation. Mais, dans une administration publique, une ténacité particulière est requise car les choses bougent généralement plus lentement. Et une hiérarchie organisationnelle inflexible ajoutée à des options de carrière limitées amplifient le problème.

Sans allié à l’intérieur, faire envisager de façon sérieuse les options du logiciel libre peut s’avérer quasiment impossible. Si de telles personnes existent, il est important de les soutenir autant que possible dans leurs luttes internes. Ceci signifie leur fournir des informations opportunes, fiables et vérifiables sur ce qui se passe dans la communauté avec laquelle l’organisation entend interagir. Ces informations doivent contenir suffisamment de détails pour fournir une image complète tout en atténuant la complexité de la communication et du chaos de planification faisant parfois partie de la façon de travailler dans le monde du logiciel libre, de façon à ce que ça devienne plus gérable et moins effrayant. L’honnêteté et le sérieux aident à construire des relations fortes avec ces personnes-clés, qui sont la base du succès à plus long terme. Elles se reposent sur vous, en tant qu’intermédiaire avec le monde merveilleux et quelque peu effrayant des communautés du logiciel libre, pour trouver des chemins qui les mèneront elles et leurs organisations à leurs objectifs. Elles prennent également des décisions en se basant largement sur la confiance personnelle. Cette confiance doit être acquise et conservée.

Afin d’y parvenir, il est important de ne pas se concentrer uniquement sur les résultats techniques des projets, mais de garder en tête les objectifs plus larges, personnels et organisationnels que l’on doit atteindre lorsqu’on travaille sur ces projets. Le succès ou l’échec du projet en cours ne dépendra peut-être pas du fait qu’un responsable de projet au sein d’une agence soit capable de ne vanter que des fonctionnalités auxiliaires à ses supérieurs à des moments plus ou moins aléatoires du calendrier. Mais cela impactera peut-être le fait que le projet suivant se fasse ou ne se fasse pas. Lorsque vous avez peu d’amis, les aider à réussir est un bon investissement.

Priorités

En tant que technophiles, les gens du logiciel libre ont tendance à se concentrer sur ce qui est nouveau, excitant et qui paraît important au niveau technologique. En conséquence de quoi, nous mettons moins l’accent sur les choses qui sont plus importantes dans le contexte d’une administration publique (souvent vaste). Mais considérez quelqu’un désireux de changer tout un ensemble de technologies dans une structure qui a plutôt tendance à rester sur les mêmes technologies pendant une longue durée. Étant donné qu’un changement brusque est difficile et coûteux, il est de loin bien plus important d’avoir de la documentation sur les choses qui ne fonctionneront pas, de façon à pouvoir les éviter ou les contourner, que de savoir qu’une version à venir fonctionnera beaucoup mieux. Il est peu probable que cette nouvelle version soit jamais disponible pour les utilisateurs dpnt nous parlons ici. Et il est bien plus simple d’avoir affaire à des problèmes connus et anticipés plutôt que d’être forcé de faire face à des surprises. Le bogue documenté d’aujourd’hui est paradoxalement préférable à sa résolution de demain avec ses effets de bord imprévisibles.

Dans une grande organisation qui utilise des logiciels pendant une longue durée, le coût d’acquisition du logiciel, que ce soit par le biais de licences ou dans le cadre de développement sur mesure de logiciels libres par contrat, a peu d’importance en comparaison du coût de maintenance et de support. Cela mène à penser que moins de fonctionnalités, plus stables, ce qui induit une moindre charge pour le  l’organisme de support, auxquelles on peut faire plus confiance et qui ont moins besoin de maintenance intensive sont meilleures que de séduisantes nouveautés, complexes et sans doute moins matures.

Alors que ces deux sentiments vont à l’encontre des instincts des développeurs de logiciels libres, ce sont ces mêmes aspects qui rendent attractif pour le secteur public le fait de payer pour le développement de logiciels libres, plutôt que de dépenser de l’argent pour des licences de produits pris au hasard. En partant d’une large palette de logiciels gratuitement disponibles, l’organisation peut investir son budget dans le perfectionnement des parties précises qui sont pertinentes pour ses propres opérations. Elle n’a ainsi pas à payer (via les coûts de licences) pour le développement de fonctionnalités clinquantes et guidées par le marché dont elle n’a pas besoin. En soumettant tout ce travail à la communauté en retour, la maintenance à long terme de ces améliorations et du logiciel de base est partagée par un grand nombre de personnes. De plus, grâce au fait que ces améliorations deviennent publiques, d’autres organisations aux besoins similaires peuvent bénéficier de celles-ci sans coût supplémentaire. Cela maximise donc l’utilité de l’argent du contribuable, ce que toute administration publique souhaite (ou devrait souhaiter).

Politique d’approvisionnement

Si les budgets informatiques des agences gouvernementales sont clairement mieux utilisés dans l’amélioration du logiciel libre et dans son adaptation à leurs besoins, pourquoi est-ce si rarement ce que l’on fait ? L’équivalence des fonctionnalités pour les types de logiciels les plus utilisés a depuis longtemps été atteinte, la convivialité est la même, la robustesse et le coût total de possession aussi. La notoriété et la connaissance sont bien sûr toujours des problèmes, mais le véritable obstacle à l’acquisition de services en logiciel libre réside dans les conditions légales et administratives sous lesquelles cela doit se produire. Changer ces conditions nécessite du travail, au niveau de la politique et du lobbying. C’est rarement possible dans le contexte d’un projet individuel. Heureusement, des organisations telles que la Free Software Foundation Europe et sa sœur aux États-Unis font du lobbying en notre nom et font lentement changer les choses. Jetons un coup d’œil à deux problèmes centraux d’ordre structurel.

Des licences, pas des services

Beaucoup de budgets informatiques sont structurés de telle façon qu’une partie de l’argent est mise de côté pour l’achat d’un nouveau logiciel ou pour le paiement continu de l’utilisation d’un logiciel sous forme de licences. Comme il était inimaginable pour ceux qui ont construit ces budgets qu’un logiciel puisse être autre chose qu’un bien achetable, représenté par une licence propriétaire, il est souvent difficile ou impossible pour les décideurs informatiques de dépenser cette même somme d’argent pour des services. La comptabilité de gestion n’en entendra simplement pas parler. Cela peut mener à la situation malheureuse où une organisation a la volonté et l’argent pour améliorer un morceau de logiciel libre afin qu’il convienne parfaitement à ses besoins, pour le déployer et pour le faire tourner pendant des années et envoyer ses contributions à la communauté, en retour, mais où cela ne peut se faire tant que toute l’affaire n’est pas enveloppée dans une vente et un achat artificiels et non nécessaires d’un produit imaginaire basé sur une licence libre.

Pièges légaux

Les cadres légaux pour les fournisseurs de logiciels supposent souvent que quiconque signant la production d’un logiciel exerce le plein contrôle des copyrights, marques déposées et brevets afférents. L’organisation cliente attend une garantie contre des risques variés de la part du fournisseur. Dans le cas où une société ou une personne produit une solution ou un service basé sur du logiciel libre, cela est souvent impossible car il y a d’autres titulaires de droits qui ne peuvent pas être raisonnablement impliqués dans l’arrangement contractuel. Ce problème apparaît plus ostensiblement dans le contexte des brevets logiciels. Il est pratiquement impossible pour un fournisseur de services de s’assurer contre les risques de contentieux de brevets, ce qui rend très risqué pour lui d’endosser la pleine responsabilité.

Prix

Historiquement, l’argument le plus vendeur du logiciel libre donné au grand public a été son potentiel pour d’économie d’argent. Le logiciel libre a en effet permis des économies à grande échelle pour beaucoup d’organisations depuis de nombreuses années. Le système d’exploitation GNU/Linux a été le fer de lance de ce développement. Ceci en raison de sa libre disponibilité au téléchargement qui a été perçue en opposition frappante avec les licences onéreuses de son principal concurrent, Microsoft Windows.

Pour quelque chose d’aussi utilisé et utile qu’un système d’exploitation, il est indéniable que le bénéfice des coûts structurels vient des coûts de développement qui sont répartis sur de nombreuses parties. Malheureusement, l’espoir que ceci reste vrai pour tous les logiciels libres a mené à la pensée irréaliste que les coûts seront toujours réduits, largement et immédiatement. D’après notre expérience, ce n’est pas vrai. Comme nous l’avons vu dans les sections précédentes de cet ouvrage, il est très logique de tirer le meilleur parti de l’argent dépensé dans l’utilisation de logiciels libres et il est probable qu’au fil du temps et pour de nombreuses organisations de l’argent puisse être économisé. Mais pour une agence isolée qui cherche seulement à déployer un logiciel libre, il devra y avoir un investissement initial et un coût nécessaire associé pour obtenir le niveau de maturité et de robustesse nécessaire.

Alors que cela semble largement raisonnable aux professionnels des opérations informatiques, il est souvent plus difficile de convaincre de cette vérité leurs supérieurs avec le bilan financier. Surtout lorsque la potentielle économie de moyens financiers a initialement été utilisée comme un argument pour faire entrer le logiciel libre, il peut s’avérer très difficile de gérer efficacement les attentes futures. Plus vite les décideurs sauront exactement de façon claire combien et dans quoi ils investissent, mieux ils accepteront de le faire sur le long terme

Le meilleur rapport qualité-prix est toujours attirant et un fournisseur de services informatiques qui cessera d’être disponible à cause de la pression des prix et n’obtiendra pas suffisamment de réussite économique est aussi peu attractif dans le logiciel libre que dans les modèles économiques basés sur des licences propriétaires. Il est donc aussi dans l’intérêt des clients que les estimations de coûts soient réalistes et que les conditions économiques dans lesquelles le travail est effectué soient durables.

Conclusion

Notre expérience montre qu’il est possible de convaincre des organismes du secteur public de dépenser de l’argent dans des services basés sur des logiciels libres. C’est une proposition intéressante qui offre une plus-value et qui a un sens politique. Malheureusement, il existe encore des barrières structurelles. Mais avec l’aide de pionniers dans le secteur public, elles peuvent être contournées. Avec un soutien suffisant de notre part à tous, ceux qui travaillent pour le logiciel libre au niveau politique finiront par les surmonter. Une communication claire et honnête sur les réalités économiques et techniques peut favoriser des partenariats efficaces qui amènent des bénéfices à la communauté du logiciel libre, aux administrations publiques utilisant ces logiciels et à ceux qui les fournissent avec les services nécessaires dans un cadre viable et durable.

La question de savoir si oui ou non il y a aura des DRM dans le HTML5 est absolument fondamentale pour le Web de demain. Ce n’est pas une question tehnique, c’est une question de partage (ou pas).

C’est pourquoi nous vous avions proposé la cinglante réponse de Cory Doctorow à Tim Berners-Lee. C’est pourquoi aussi nous avons traduit cet article très clair de l’Electronic Frontier Foundation qui en appelle à se mobiliser, par exemple en signant la pétition lancée par la Free Software Foundation.

Défense du web ouvert : pas de DRM dans les standards W3C

Defend the Open Web: Keep DRM Out of W3C Standards

Peter Eckersley et Seth Schoen – 20 mars 2013 – EFF.org
(Traduction : tcit, ZeHiro, audionuma, goofy, audionuma, Asta)

Un nouveau front est ouvert dans la bataille contre les DRM. Ces technologies, qui sont censées permettre le respect du copyright, n’ont jamais permis de rémunérer les créateurs. Par contre, que ce soit volontairement ou par accident, leur véritable effet est d’interférer avec l’innovation, l’usage légitime, la concurrence, l’interopérabilité et notre droit légitime à posséder nos biens.

C’est pourquoi nous avons été consternés d’apprendre qu’une proposition est actuellement à l’étude au sein du groupe de travail HTML5 du World Wide Web Consortium (W3C) pour intégrer les DRM dans la prochaine génération de standards fondamentaux du Web. Cette proposition est dénommée Encrypted Media Extensions (Extensions pour les médias chiffrés, EME). Son adoption représenterait une évolution catastrophique et doit être stoppée.

Durant les deux dernières décennies, il y a eu un combat continu entre deux visions de la manière dont les technologies d’Internet doivent fonctionner. L’une des philosophies est que le Web doit être un écosystème universel basé sur des standards ouverts et que quiconque peut implémenter sur un pied d’égalité, n’importe où, n’importe quand, sans permissions ni négociations. C’est cette tradition technologique qui a produit HTML et HTTP pour commencer, et des innovations qui ont marqué leur époque comme les wikis, les moteurs de recherche, les blogs, les messageries sur le Web, les applications écrites en JavaScript, les cartes en ligne réutilisables, et une centaine de millions de sites Web que ce paragraphe serait trop court pour énumérer.

L’autre vision est incarnée par les entreprises qui ont essayé de s’approprier le contrôle du Web avec leurs propres extensions propriétaires. Cela s’est manifesté avec des technologies comme Flash d’Adobe, Silverlight de Microsoft, et des pressions venant d’Apple, des fabricants de téléphonie, et d’autres, en faveur de plateformes hautement restrictives. Ces technologies sont conçues pour n’être disponibles qu’auprès d’une seule source ou nécessiter une autorisation pour toute nouvelle implémentation. À chaque fois que ces techniques sont devenues populaires, elles ont infligé des dommages aux écosystèmes ouverts qui les entourent. Les sites Web qui utilisent Flash ou Silverlight ne peuvent en général pas être référencés correctement, ne peuvent pas être indexés, ne peuvent être traduits automatiquement, ne peuvent être consultés par les personnes en situation de handicap, ne fonctionnent pas sur tous les terminaux de consultation, et posent des problèmes de sécurité et de protection de la vie privée à leurs utilisateurs. Les plateformes et les équipements qui restreignent la liberté de l’utilisateur freinent inévitablement des innovations importantes et entravent les compétitions sur le marché.

La proposition EME est entachée par plusieurs de ces problèmes car elle abandonne explicitement la responsabilité de la question de l’interopérabilité et permet aux sites Web de requérir des logiciels propriétaires de tierces-parties, voire du matériel ou un système d’exploitation spécifiques (tout cela mentionné sous le nom générique de « content decryption modules » (« modules de déchiffrage du contenu », CDM), dont aucun n’est spécifié par EME). Les auteurs d’EME soutiennent que les CDM, ce qu’ils font et d’où ils viennent, est totalement hors du champ d’EME, et qu’EME ne peut être considéré comme un DRM puisque tous les CDM ne sont pas des DRM. Néanmoins, si l’application client ne peut prouver qu’elle exécute le module propriétaire spécifique que le site réclame, et n’a donc pas de CDM qualifié, elle ne peut afficher le contenu du site. De manière perverse, c’est exactement à l’opposé des raisons qui font que le W3C existe. Le W3C est là pour créer des standards lisibles, qui soient implémentables par le public et qui garantissent l’interopérabilité, et non pas pour favoriser une explosion de nouveaux logiciels mutuellement incompatibles et de sites et services qui ne sont accessibles qu’à certains équipements ou applications. Mais la proposition EME va justement apporter cette dynamique anti-fonctionelle dans HTML5, risquant même un retour au « bon vieux temps d’avant le Web » où l’interopérabilité était volontairement restreinte.

Étant donné l’extrême méfiance de la communauté des standards ouverts à l’encontre des DRM et de leurs conséquences sur l’interopérabilité, la proposition de Google, Microsoft et Netflix affirme que « aucun DRM n’est ajouté à la spécification HTML5 » par EME. C’est un peu comme dire « nous ne sommes pas des vampires, mais nous allons les inviter chez vous ».

Les promoteurs d’EME semblent affirmer que ce n’est pas un modèle de DRM. Mais l’auteur de la spécification Mark Watson a admis que « effectivement, nous nous intéressons aux cas d’utilisation que la plupart des gens appellent DRM » et que les implémentations nécessiteront par nature des aspects secrets qui sont hors du champ de la spécification. Il est difficile de soutenir que EME n’a rien à voir avec les DRM.

Les propositions sur les DRM au W3C sont là pour une raison simple : il s’agit d’une tentative d’apaiser Hollywood, qui est irrité par Internet au moins depuis que le Web existe, et a toujours réclamé qu’une infrastructure technique avancée permette de contrôler ce qui se passe sur l’ordinateur du public. Le sentiment est que Hollywood ne permettra jamais la distribution des films sur le Web s’il n’est pas possible de les accompagner de DRM. Mais la crainte que Hollywood puisse récupérer ses billes et quitter le Web est illusoire. Chaque film que Hollywood distribue est déjà disponible pour ceux qui veulent réellement pirater une copie. Une énorme quantité de musique est vendue par iTunes, Amazon, Magnatunes et des dizaines d’autres sites sans qu’il n’y ait besoin de DRM. Les services de streaming comme Netflix et Spotify ont réussi parce qu’ils proposent une expérience plus pratique que le piratage, pas parce que les DRM favorisent leur modèle économique. La seule explication raisonnable pour que Hollywood réclame des DRM est que les producteurs de films veulent contrôler comment les technologies grand public sont conçues. Les producteurs de films ont utilisé les DRM pour faire respecter des restrictions arbitraires sur leurs produits, comme l’interdiction de l’avance rapide ou des restrictions géographiques, et ont créé un système complexe et onéreux de « mise en conformité » pour les entreprises technologiques qui donnent à un petit groupe de producteurs de contenu et aux grandes sociétés du secteur des technologies un droit de veto sur l’innovation.

Trop souvent, les entreprises technologiques se sont lancées dans une course l’une contre l’autre pour bâtir un fouillis logiciel qui corresponde aux caprices de Hollywood, abandonnant leurs utilisateurs dans cette course. Mais les standards ouverts du Web sont un antidote à cette dynamique, et ce serait une terrible erreur pour la communauté du Web de laisser la porte ouverte à la gangrène anti-technologique de Hollywood dans les standards W3C. Cela minerait l’objectif principal de HTML5 : créer un éco-système ouvert alternatif à toutes les fonctionalités qui manquaient dans les standards Web précédents, sans les problèmes de limitations des équipements, d’incompatibilité entre plateformes et l’absence de transparence qui fut créée par des plateformes comme Flash. HTML5 était censé être mieux que Flash, et en exclure les DRM est exactement ce qui le rendrait meilleur.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Ouve, Julius22, Sphinx, Garburst, goofy, peupleLà, audionuma, lamessen

Comment demander de l’argent

Selena Deckelmann

Selena Deckelmann est une importante contributrice de PostgreSQL. Elle donne des conférences dans le monde entier sur les logiciels libres, les communautés de développeurs et du trollage. Elle s’intéresse à l’ouverture des données publiques de la ville de Portland, aux poulets d’appartement et à la recherche de solutions pour permettre aux bases de données de fonctionner plus vite.

Elle a fondé Postgres Open, une conférence dédiée aux activités économiques autour de PostgreSQL et au bouleversement du secteur des bases de données. Elle a fondé et co-présidé Open Source Bridge, une conférence de développeurs pour les citoyens open source. Elle a fondé la Conférence PostgreSQL, une brillante série de conférences sur la côte Est et la côte Ouest des États-Unis pour PostgreSQL. Elle fait actuellement partie du comité de programme de PgCon, de la conférence des utilisateurs MySQL et de OSCON Data. Elle est l’une des contributrices au manuel du mentor des Google Summer of Code, et du Guide des Étudiants. Elle est conseillère pour l’initiative Ada et membre du conseil de la société Technocation.

Si je retrace mon parcours depuis la première fois où j’ai démarré un PC sous Linux en 1994, une chose ressort clairement de mon expérience avec l’open source : j’aurais aimé savoir comment demander de l’argent. Demander de l’argent est difficile. J’ai écrit des demandes de subventions, demandé des augmentations, négocié des salaires et des tarifs horaires de consultante et levé des fonds pour des conférences à but non lucratif. Après de nombreuses tentatives et échecs, j’ai développé une méthode qui fonctionne ! Ce qui suit est un condensé des trucs et astuces que j’ai utilisés durant ces cinq dernières années pour augmenter les fonds pour des non-conférences, des sprints de code d’une journée et des conférences de plusieurs jours à propos de la culture et des logiciels open source.

La méthode pour obtenir des fonds pour une conférence comporte six étapes :

1. identifier un besoin ;
2. en parler à quelqu’un ;
3. demander de l’argent ;
4. récupérer l’argent ;
5. dépenser l’argent ;
6. Remercier.

Identifiez un besoin

Votre première mission en tant qu’organisateur de conférences consiste à expliquer pourquoi vous mettez en place une conférence de plus, en quoi elle sera utile à ceux qui y assisteront et quel intérêt un sponsor aurait à vous financer. On appelle ça « écrire un dossier de présentation ». Les éléments principaux d’un tel dossier sont les suivants :

• l’objectif : en un paragraphe, expliquez pourquoi vous faites la conférence. Qu’est-ce qui vous a poussé à rassembler des gens ? Et qui seront les participants ? De quoi parleront-ils une fois là-bas ? Si vous avez un sujet ou un but particulier en tête, mentionnez-le. Expliquez également pourquoi vous avez choisi tel endroit pour l’événement. Y a-t-il un lien avec le sujet de la conférence ? Est-ce que les personnes intéressantes s’y trouvent ? Est-ce qu’il y a un sponsor ? Enfin, mettez à disposition les chiffres intéressants à propos des événements précédents, comme le nombre de participants et des informations pertinentes sur les intervenants ou des détails sur le lieux choisi ;

• les possibilités de mécénat et les bénéfices escomptés : cette partie du dossier va mettre en relief ce que les sponsors peuvent attendre de votre conférence. En règle générale, on y expose les retours sont évalués en termes financiers, mais on peut également y décrire des avantages comme des travaux en nature ou du bénévolat. Commencez simplement. Traditionnellement, les parrainages financiers des événements sont assurés par des services des ressources humaines qui cherchent à embaucher ou par des départements commercial-marketing qui cherchent à faire connaître leurs produits ou services. Voici, entre autres, le genre d’avantages que les sponsors en attendent : la mention du sponsor sur un site Web, dans les messages ou tweets pour les participants, l’accès à la liste des adresses électroniques ou aux informations sur les profils des participants, la présence des logos et des étiquettes sur les pochettes, tours de cou et autres gadgets distribués lors de la conférence, de même au moment des pauses cafés, des repas et casse-croûtes. Il leur faut aussi un stand sur la zone de la conférence et de l’espace publicitaire sur le programme de la conférence. Pensez aussi aux choses originales qui permettront de vous démarquer, à travers le déroulement et le lieu de la conférence. Par exemple, à Portland, il y a une boutique de beignets très populaire, avec un service de livraison. Nous avons trouvé un sponsor, et nous avons obtenu la permission d’amener le camion de livraison juste à l’endroit où nous étions et nous avons servi des beignets gratuitement pour le petit-déjeuner. Vous trouverez ci-dessous des liens pour des exemples de dossiers. Ils correspondent tous à de grosses conférences, donc vous n’obtiendrez peut-être pas le même résultat. J’ai déjà fait un dossier, avec une seule possibilité de parrainage, et l’accord était qu’en échange de la présence d’un de ses employés à la conférence, les organisateurs mentionnaient clairement l’entreprise et la remerciaient pour son soutien. Quelques entreprises : OSCON, Open Source Bridge, MeeGo San Francisco. 

• le contrat : toujours inclure un contrat avec votre dossier. Cela établit les attentes et les engagements ainsi que le calendrier et peut éviter beaucoup de problèmes en chemin. Je ne suis pas un avocat, donc ce qui suit relève plus de mon expérience que des conseils juridiques. Pour les événements plus mineurs, j’écris un contrat très simple qui expose mes attentes : les sponsors promettent de payer à une certaine date et je promets de tenir l’événement à une certaine date. Copier un contrat existant est quelque chose de délicat car les lois changent suivant les différents états et pays. J’ai consulté un avocat qu’un gestionnaire chevronné d’une communauté de l’open source m’avait recommandé. Le cabinet d’avocats a été assez agréable pour gracieusement créer des contrats et réviser des contrats entre nous et les hôtels. Le Software Freedom Law Center peut vous indiquer un avocat approprié si vous n’en avez pas.

Maintenant que vous avez créé le dossier de présentation, vous avez besoin de parler à quelques personnes.

Parlez-en

L’étape la plus difficile pour moi, c’est de faire passer le mot au sujet de mes événements ! Entraînez-vous à présenter votre événement en une ou deux phrases. Transmettez ce qui vous emballe et ce qui devrait emballer les autres.

Au fil des ans, j’ai appris qu’il fallait que je commence à parler SANS DÉLAI à mes connaissances plutôt que de m’inquiéter de savoir exactement quelles étaient les bonnes personnes à qui parler. Faites une liste des personnes à qui parler et que vous connaissez déjà et commencez à cocher cette liste.

La meilleure manière parler de votre projet est de le faire en personne ou au téléphone. Ainsi, vous ne spammez pas les les gens, vous captez leur attention et vous pouvez avoir un retour immédiat sur votre argumentaire. Les gens sont-ils enthousiastes ? Posent-ils des questions ? Ou bien trouvent-ils que c’est rasoir ? À qui d’autre pensent-ils que vous devriez en parler ? Demandez-leur ce qu’ils en pensent et comment vous pourriez rendre votre argumentaire plus attractif, plus intéressant, de sorte qu’ils en aient pour leur argent !

Une fois que vous aurez trouvé les mots-clés de votre argumentaire, écrivez-le et envoyez quelques courriels. Demandez des retours sur votre courriel et terminez toujours par un appel à agir avec une échéance pour la réponse. Gardez la trace des personnes qui répondent, de leurs réponses, et du moment favorable pour une relance de chacune d’elles.

Demandez de l’argent

Armé de votre dossier et de votre argumentaire réglé aux petits oignons, commencez à approcher des sociétés pour financer votre événement. À chaque fois que je lance une nouvelle conférence, je fais une liste de questions à son propos et je réponds à chacune avec une liste de personnes et de sociétés :

• Parmi les personnes que je connais, qui va trouver que c’est une idée géniale et faire la promo de mon événement  (supporters) ;
• Quelles sont les personnes dont la présence à la conférence serait vraiment sympa  (experts reconnus) ;
• Quelles sociétés ont des produits qu’elles voudraient promouvoir à mon événement  (marketing) ;
• Qui voudrait embaucher les personnes qui participent  (recruteurs) ;
• Quels projets libres et open source voudraient recruter des développeurs  (recruteurs open source)

En utilisant ces listes, envoyez votre brochure à travers le monde ! Voici un aperçu de la façon dont j’organise le processus de demande : je commence par envoyer les dossiers de présentation à mes supporters. J’en glisse aussi une copie aux experts, et je les invite à assister à la conférence ou à y intervenir. Je contacte ensuite les agences de publicité, les recruteurs et les recruteurs open source (parfois ça se recoupe !). En parallèle, j’ai généralement ouvert les inscriptions à la conférence et annoncé quelques allocutions ou événements spéciaux. Je croise les doigts pour que ça pousse à quelques inscriptions, que ça aide les sponsors à sentir que cette conférence va certainement avoir lieu et que tout va bien se passer.

Récupérez l’argent

Si tout se passe comme prévu, des sociétés et des individus vont commencer à vous proposer de l’argent. Lorsque cela se produit, vous aurez besoin de deux choses très importantes :

• un modèle de factures ou de devis ;
• un compte en banque pour recueillir les fonds.

Les modèles de factures sont simples à réaliser. J’utilise une feuille de calcul Google que j’actualise pour chaque facture. Vous pourriez facilement utiliser OpenOffice.org ou même TeX (si quelqu’un peut m’envoyer un modèle de facture LaTeX, merci d’avance !). On peut trouver des exemples de factures à l’adresse http://www.freetemplatesdepot.com.

Les éléments les plus importants d’une facture sont : le mot FACTURE, un numéro unique de facture, le nom et les informations de contact du sponsor, le montant que le sponsor est censé verser, les termes de l’accord (à quelle date le sponsor est censé payer, quelles sont les pénalités en cas de non-paiement) et le montant total dû. Il faut ensuite envoyer une copie de la facture à la société. Gardez une copie pour vous !

Certaines sociétés peuvent exiger que vous remplissiez des formulaires plus ou moins complexes pour vous reconnaître, vous ou votre organisation, comme un fournisseur. De la paperasserie. Beurk ! Les délais de paiement pour de grandes entreprises peuvent atteindre deux mois. Les exercices budgétaires des sociétés sont en général annuels. Regardez si une société a un budget disponible pour votre événement et si vous pouvez être inclus dans les prévisions budgétaires de l’année suivante, si vous avez manqué l’occasion pour l’année en cours.

Le compte en banque peut être votre compte personnel, mais c’est risqué pour vous. Pour un événement à plusieurs milliers d’euros, vous préférerez peut-être trouver une ONG ou une association loi de 1901 qui peut détenir et dépenser les fonds en votre nom. Si votre conférence est à but lucratif, vous devriez consulter un comptable sur la meilleure manière de gérer ces fonds. Trouver une organisation sans but lucratif avec laquelle travailler peut se résumer à contacter une fondation qui gère un projet de logiciel libre.

Maintenant, passons à ce qui justifie tout ce processus : dépenser les dons durement acquis !

Dépensez l’argent

Maintenant que vos sponsors ont payé, vous pouvez dépenser l’argent.

Créez un budget qui détaille vos postes de dépenses et quand vous aurez besoin de les dépenser. Je conseille d’obtenir trois devis pour les produits et services qui ne vous sont pas familiers, simplement afin de vous faire une idée sur ce qu’est un prix correct. Faites comprendre aux fournisseurs que vous contactez que vous faites jouer la concurrence.

Une fois que j’ai établi une relation avec une entreprise, j’ai tendance à faire des affaires avec eux d’un an sur l’autre. J’aime avoir de bonnes relations avec les fournisseurs et je trouve que même si je paie un peu plus que si je faisais jouer la concurrence chaque année, je finis par gagner du temps et par obtenir un meilleur service de la part d’un vendeur qui me connaît bien.

Pour les petits événements, vous pouvez garder une trace de vos dépenses dans un tableur assez simple. Pour les projets plus grands, demander à un comptable ou utiliser des logiciels de comptabilité peut être utile. Voici une liste des alternatives libres à Quicken (à différents niveaux et avec différents aspects !).

Le plus important est de garder une trace de toutes vos dépenses et de ne pas dépenser de l’argent que vous n’avez pas ! Si vous travaillez avec une organisation à but non lucratif pour gérer le budget de l’événement, demandez-lui de l’aide et des conseils avant de commencer.

Remerciez

Il existe de nombreuses manières de remercier les gens et les entreprises qui ont apporté leur soutien à votre manifestation. Encore plus important, suivez toutes les promesses que vous avez faites dans le dossier. Communiquez à chaque fois qu’un engagement est tenu !

Durant la manifestation, trouvez des moyens d’entrer en contact avec les sponsors, en désignant un bénévole pour les inscrire et de les inscrire eux-mêmes auprès de vous.

Après la manifestation, assurez-vous de remercier individuellement chaque sponsor et chaque bénévole pour sa contribution. Une association avec laquelle je travaille envoie des remerciements écrits à chaque sponsor en début d’année.

D’une manière générale, la communication est le terreau fertile de la levée de fonds. Porter attention aux sponsors et construire des relations authentiques avec eux aide à trouver plus de sponsors, et à construire votre réputation de bon organisateur de manifestations.

Leçons apprises

Après avoir créé et animé des dizaines de manifestations, les deux aspects les plus importants que j’en tire ont été de trouver des mentors et d’apprendre à bien communiquer.

Les mentors m’ont aidée à transformer des coups de gueule en essais littéraires, du fouillis en dossiers et des conversations difficiles en perspectives. J’ai trouvé des mentors dans des entreprises qui parrainaient mes conférences, et me faisaient des retours détaillés, parfois pénibles. Et j’ai trouvé des mentors parmi les bénévoles qui passaient des centaines d’heures à écrire du logiciel pour mes manifestations, à recruter des orateurs, à documenter ce que nous étions en train de faire, et à poursuivre la conférence après moi.

Apprendre à bien communiquer prend du temps, et c’est l’occasion de faire de nombreuses erreurs. J’ai appris à mes dépens que ne pas développer de relations avec les meilleurs sponsors signifie ne pas être financé l’année suivante ! J’ai aussi appris que les gens sont capables d’une formidable indulgence envers les erreurs, dès lors que vous communiquez tôt et souvent.

Bonne chance dans votre recherche de fonds, et merci de me dire si ce qui précède vous a aidé.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Ouve, Julius22, Sphinx, CoudCoud, grosfar, lum’, goofy, peupleLà, lamessen

Nous ne sommes pas fous… Nous organisons des conférences !

Gareth J. Greenaway

Gareth J. Greenaway s’est impliqué activement dans la communauté du logiciel libre et open source depuis 1997 après avoir découvert Linux. Sa contribution majeure a consisté à regrouper des gens ayant la même opinion pour apprendre et expérimenter de nouveaux éléments de logiciel libre et open source. Cette implication a débuté avec un petit groupe d’utilisateurs de Linux (un « GUL ») et s’est développée avec l’organisation de la « Southern California Linux Expo », aussi connue sous le nom de SCALE. En tant que membre fondateur de cet évènement, Gareth remplit actuellement deux fonctions importantes au sein de l’organisation. La première est la gestion des conférences et la seconde concerne les relations avec la communauté.

J’ai commencé à écrire cette section avec ce que je pensais être les besoins et les étapes pour organiser une conférence sur le libre et l’open source. Cependant, une grande partie de ce que je trouvais à dire avait déjà été abordé par Dave Neary, expert en gestion de communautés. Donc, pour éviter de répéter et de recouper ce que Dave voulait expliquer, j’ai décidé de partager différentes histoires de l’organisation de SCALE et les leçons que j’en ai tiré pendant ces années.

Trop d’énergie !

SCALE a commencé il y a maintenant neuf ans avec des membres de trois groupes locaux d’utilisateurs de Linux, ce n’était à l’origine qu’un modeste évènement régional organisé par l’un de ces groupes. La première expérience fut vraiment enrichissante. Beaucoup de leçons en ont été tirées. On courait un peu partout et l’évènement semblait se dérouler à une vitesse folle. Étant donné qu’aucun de nous n’avait encore organisé d’évènement où il fallait se soucier des risques de surtension ou de consommation électrique, nous n’y avons pas pensé, et, du coup, nous avons dû ré-enclencher les disjoncteurs de la salle plusieurs fois pendant l’évènement.

Ça va marcher… c’est sans fil !

Le deuxième SCALE a pris en compte un grand nombre de leçons apprises l’année précédente mais un nouveau lieu de rencontre allait donner de nouvelles leçons. Le centre de conférences de Los Angeles est le lieu où s’est tenu SCALE 2, il fournissait un espace bien plus grand pour installer l’évènement. Le nouveau lieu nous a aussi permis d’apprendre notre première leçon sur les contrats avec un grand organisme pour gérer les choses telles que l’équipement audio et vidéo, l’accès à Internet et le matériel d’exposition.

Compte tenu de la situation de l’évènement à l’intérieur du centre de conférences, nous avons dû positionner les comptoirs d’enregistrement dans une zone qui, tout en étant visible des participants qui arrivaient, se trouvait à une certaine distance du reste du salon. Nos possibilités pour fournir un accès réseau à la zone d’enregistrement étaient limitées car les règles de protection anti-incendie proscrivaient l’utilisation de câbles ; le sans-fil était donc l’unique option.

Tout a été mis en place très tôt le jour du salon et fonctionnait parfaitement bien, jusqu’à ce que cela cesse mystérieusement de marcher. La connexion sans fil, fournissant l’accès au réseau indispensable au comptoir d’enregistrement, a tout simplement disparu. Nous avons alors vécu beaucoup de tentatives de dépannages, beaucoup de déplacements d’équipements et d’antennes et beaucoup de frustration. « Ça devrait fonctionner. » était la seule conclusion à laquelle tout le monde pouvait parvenir, sans trop savoir pourquoi cela ne fonctionnait pas.

Soudain, un des membres de l’équipe, qui s’était tenu à l’écart de la séance de dépannage, a appelé tout le monde à venir à l’endroit où il se trouvait. En face d’une grande fenêtre qui surplombait un grand hall de réunion, nous avons tout à coup tous vu ce qu’il désirait nous faire voir. En-dessous de nous il y avait des dizaines de lumières clignotantes, tournantes et pulsantes qui nous regardaient. Des centaines d’appareils électroniques avec des lumières clignotantes, des sirènes et des panneaux à LED (diodes électro-luminescentes), interférant narquoisement avec les signaux sans fil de nos pauvres points d’accès. Nous avons soudain réalisé que nos heures de travail à tenter de résoudre ce problème de sans-fil avaient été vaines. Finalement, nous avons déroulé un câble Ethernet, l’avons scotché de la manière la plus sécurisée que nous avons pu, et nous avons dit une petite prière pour que le chef des pompiers ne fasse pas d’inspection surprise.

Soirées de gala, tireurs d’élite et disparition mystérieuse de mallette IBM

L’une des anecdotes les plus célèbres dans l’histoire de SCALE est sans doute celle des incidents et péripéties qui sont survenus pendant SCALE 3. Ces aventures sont bien connues, et si vous assistiez à SCALE cette année-là, vous n’avez pas pu y échapper.

Le troisième SCALE devait se dérouler encore une fois au centre de conférences de Los Angeles au L.A. Convention Center. Tout le travail de planification et d’organisation avait été mené en amont pendant de nombreux mois et tout s’annonçait bien. Trois semaines environ avant l’évènement, nous avons reçu des informations à propos de plusieurs routes qui seraient fermées autour du centre de conférences à cause d’une soirée de gala qui devait avoir lieu. À cause de ces fermetures de routes, il n’y avait plus qu’une voie d’accès pour accéder au centre et en repartir, ce qui est loin d’être idéal. Fort heureusement, nous avons eu le temps d’avertir tous ceux qui venaient à l’évènement et de leur indiquer les routes fermées à la circulation et les itinéraires alternatifs. Cette année-là, c’était aussi la première fois que SCALE devait se dérouler sur deux jours, dans l’espoir de répartir un peu les choses pour ne pas être autant dans la précipitation et la frénésie.

L’un des plus anciens sponsors et exposants de SCALE est IBM. Ils ont toujours été une plus-value appréciée, mais, malheureusement, leur participation s’est généralement accompagnée de quelques difficultés. La veille de l’évènement, comme d’habitude, avait été réservée à la mise en place pour permettre à l’équipe de SCALE de tout installer et aux exposants de préparer leurs stands. C’est également le jour de réception de tous les paquets envoyés par les exposants. IBM avait prévu de présenter une nouvelle ligne de serveurs sur le salon et avait fait expédier un de ces serveurs au centre de conférences ; malheureusement, il n’avait pas été livré sur leur stand et personne dans le centre de conférences ne savait où pouvait bien se trouver le colis. Malgré de nombreuses heures à chercher dans tous les endroits possibles à l’intérieur du centre de conférences, nous n’avions pas la moindre piste.

Il se trouve que le gala qui devait avoir lieu quelques jours plus tard avait loué un certain nombre de pièces pour en faire des bureaux et des espaces de stockage. Dans un éclair de génie, le coordinateur de l’évènement qui aidait à la recherche suggéra que nous pourrions chercher dans un de leurs espaces de stockage en espérant que la mallette d’IBM ait été livrée là par accident. La pièce en question était un petit placard de rangement dans lequel nous nous sommes trouvés face à des montagnes de boîtes, du sol jusqu’au plafond, remplies de tickets pour la soirée de gala à venir. Derrière ces boîtes, dans un coin, il y avait une grande mallette bleue avec le logo IBM bien visible. Crise évitée !

Le reste de l’évènement se déroula sans heurts et pratiquement sans incidents. Alors que l’évènement se finissait, une petite foule commença à se former près de grandes fenêtres donnant sur la rue. Alors que je passais à cet endroit, je pris conscience de ce que tout le monde était en train de regarder. Plusieurs silhouettes, toutes vêtues de noir, se déplaçaient sur les toits des bâtiments le long de la rue. Toutes ces silhouettes portaient des fusils de précision et étaient des membres de l’équipe du SWAT de la police de Los Angeles qui se préparaient pour la soirée de gala qui allait avoir lieu plus tard. Ce fut sans conteste une sortie mémorable du centre de conférences.

Pas de chambre à l’hôtel

Le quatrième SCALE a occasionné un nouveau changement de lieu. Cette fois-ci, nous sommes passés à un hôtel à la place d’un centre de conférences. Comme avec les années de plus en plus de personnes voyageaient pour assister à SCALE et séjournaient dans des hôtels proches, nous avons décidé d’étudier la possibilité que SCALE ait lieu dans un hôtel. Nous avons parcouru la région et avons fini par consulter un organisateur d’évènements pour trouver le bon endroit pour le nôtre. En nous installant dans un hôtel proche de l’aéroport de Los Angeles, la planification commença. Tenir l’évènement dans un hôtel nous a rapidement confrontés à de nouvelles problématiques propres aux hôtels. Une des plus importantes leçons que nous avons alors apprises a été de s’assurer que tous les contrats comportaient une clause convenue d’annulation.

À peu près cinq semaines avant l’évènement, nous avons reçu un appel des responsables du lieu qui nous informaient que leur entreprise annulait notre évènement pour attribuer le lieu à une autre manifestation. Cela a évidemment été un choc pour nous et nous a plongé dans la plus grande confusion. Le contrat avec l’hôtel ne comprenait pas une ligne sur les cas de résiliation pour changement de lieu, mais précisait seulement qu’ils pouvaient annuler la manifestation sans aucun motif.

Après un grand nombre de coups de téléphone et de tractations avec les responsables du lieu initial, ils ont fini par accepter de nous indemniser pour nous aider à migrer vers un lieu de remplacement. Lequel nous a consenti les mêmes conditions pour tout ce qui concernait l’électricité, l’accès à Internet et l’équipement audio et vidéo. Tout s’est bien passé et l’équipe de SCALE en a tiré une précieuse leçon sur la façon de négocier ses futurs contrats.

Rappel !

Tout compte fait, organiser une conférence est une entreprise gratifiante et un excellent moyen de rendre à la communauté ce qu’elle nous a apporté. Les conférences constituent un moment privilégié car elles permettent des échanges en personne dans un monde qui repose couramment sur des moyens de communication virtuels.

Voici les conseils que je donnerais à des organisateurs de conférences :

• commencez modestement, ne vous lancez pas dans un gigantesque évènement dès la première année ;
• saisissez les occasions, faites des erreurs, n’ayez pas peur de l’échec ;
• tout est dans la communication !

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Ouve, merlin8282, Julius22, Sphinx, CoudCoud, lum’, goofy, peupleLà, Alpha, Peekmo, audionuma, lamessen

Rassembler les gens

Dave Neary

Dave Neary travaille sur des projets libres et open source depuis qu’il a découvert Linux en 1996. C’est un contributeur de longue date à GNOME et à GIMP. Il travaille à plein temps depuis 2007 pour aider des entreprises à se réconcilier avec les logiciels développés de façon communautaire. Durant cette période, il a travaillé sur divers projets dont OpenWengo, Maemo et Meego, qui étaient liés à de l’événementiel, à des méthodes de travail communautaires, à de la gestion de produits ainsi qu’à de la gestion d’outils d’analyse d’une communauté. Il s’est impliqué, en tant que bénévole, dans l’organisation du GUADEC, du Desktop Summit, du Libre Graphics Meeting, de la GIMP Conference, d’Ignite Lyon, de l’Open World Forum et de la MeeGo Conference.

L’une des choses les plus importantes que vous puissiez faire dans un projet lié au logiciel libre, à part écrire du code, c’est de rassembler les principaux contributeurs aussi souvent que possible. J’ai eu la chance de pouvoir organiser un certain nombre d’événements au cours de ces dix dernières années, mais aussi d’observer les autres et d’apprendre à leur contact pendant ce temps. Voici quelques-unes des leçons que j’ai apprises au cours du temps, grâce à cette expérience.

1. Le lieu

Le point de départ pour la plupart des réunions ou des conférences, c’est le lieu. Si vous réunissez un petit groupe (moins de dix personnes), il suffit bien souvent de choisir une ville et de demander à un ami qui possède une entreprise ou qui est professeur d’université de vous réserver une salle. Vous aurez sans doute besoin d’une organisation plus formelle dès qu’il y aura plus de monde à accueillir.

Si vous ne faites pas attention, le lieu de l’événement sera une grande source de dépenses et il vous faudra trouver l’argent correspondant quelque part. Mais si vous êtes futé, vous pouvez vous débrouiller pour obtenir assez facilement une salle gratuitement.

Voici quelques-unes des stratégies qu’il serait intéressant d’essayer :

• Intégrez-vous au sein d’un autre événement : le Linux Foundation Collaboration Summit, OSCON, LinuxTag, GUADEC et beaucoup d’autres conférences accueillent volontiers des ateliers ou des rencontres pour de plus petits groupes. Le GIMP Developers Conference en 2004 a été le premier rassemblement que j’ai organisé, et afin de ne pas avoir à subir les problèmes inhérents au fait de trouver la salle, une date qui convient à tout le monde et ainsi de suite, j’ai demandé à la GNOME Foundation si ça ne les dérangeait pas de nous laisser un peu d’espace lors de la GUADEC — et ils ont accepté. Tirez parti de l’organisation d’une conférence plus grande, et vous pourrez en plus assister à cette grande conférence par la même occasion !
• Demandez aux universités environnantes si elles n’ont pas des salles disponibles. Ça ne fonctionnera plus une fois que vous aurez dépassé une certaine taille, néanmoins, vous pouvez vous renseigner en particulier dans les universités dont certains chercheurs sont des membres du Linux User Group (LUG) [NdT : groupe d’utilisateurs de Linux] local. Ils peuvent en parler avec leur directeur de département afin de réserver un amphithéâtre et quelques salles de classe pour un week-end. Un grand nombre d’universités vous demanderont de faire un communiqué de presse et d’être mentionnées sur le site Web de la conférence, ce qui est un juste retour des choses. Le premier Libre Graphics Meeting s’est déroulé gratuitement à CPE Lyon et le GNOME Boston Summit a été accueilli gratuitement pendant des années par le MIT.
• Si le lieu de rendez-vous ne peut pas être gratuit, voyez si quelqu’un d’autre ne peut pas le financer. Lorsque votre conférence commence à accueillir plus de 200 personnes, la plupart des salles seront payantes. Héberger une conférence coûtera beaucoup d’argent à celui qui prête les locaux, et c’est une part importante dans le modèle économique des universités que d’organiser des conférences lorsque les étudiants sont partis. Mais ce n’est pas parce que le centre de conférence ou l’université ne peut pas vous accueillir gratuitement que cela signifie que vous devez être la personne qui paye. Les collectivités territoriales aiment bien être impliquées lorsqu’il s’agit d’organiser des événements importants dans leur région. Le GUADEC à Stuttgart, le Gran Canaria Desktop Summit et le Desktop Summit à Berlin ont tous été financés par la région d’accueil en ce qui concerne la salle. S’associer avec une région présente un avantage supplémentaire : elles ont souvent des liens avec les entreprises et la presse locale, ce qui représente des ressources que vous pouvez utiliser afin d’obtenir de la visibilité et peut-être même des sponsors pour votre conférence.
• Faites un appel d’offres : en incitant les groupes qui souhaitent héberger la conférence à déposer une offre, vous les incitez aussi à trouver une salle et à discuter avec les partenaires locaux avant de vous décider sur l’endroit où aller. Vous mettez aussi les villes en concurrence, et comme pour les candidatures aux Jeux Olympiques, les villes n’apprécient pas de perdre les compétitions auxquelles elles participent !

2. Le budget

Les conférences coûtent de l’argent. Ce qui peut coûter le plus cher pour une petite rencontre, ce sont les frais de déplacement des participants. Pour une conférence plus importante, les principaux coûts seront l’équipement, le personnel et la salle. Chaque fois que j’ai dû réunir un budget pour une conférence, mon approche globale a été simple :

• décider de la somme d’argent nécessaire pour réaliser l’événement ;
• collecter les fonds jusqu’à atteindre ce montant ;
• arrêter la collecte et passer aux étapes suivantes de l’organisation.

Lever des fonds est une chose difficile. On peut vraiment y passer tout son temps. Au bout du compte, il y a une conférence à préparer, et le montant du budget n’est pas la préoccupation principale de vos participants.

Rappelez-vous que votre objectif principal est de réunir les participants du projet afin de le faire avancer. Alors, obtenir des réponses de participants potentiels, organiser le logement, la salle, les discours, la nourriture et la boisson, les activités sociales et tous les autres aspects de ce à quoi les gens s’attendent lors d’un événement… tout cela est plus important que la levée de fonds.

Bien sûr, de l’argent est nécessaire pour être capable d’organiser tout le reste. Alors, trouver des sponsors, décider de leurs niveaux de participation et vendre la conférence est un mal nécessaire. Mais une fois que vous avez atteint le montant nécessaire pour la conférence, vous avez vraiment mieux à faire.

Il existe quelques sources potentielles de financement pour préparer une conférence — combiner ces sources semble, selon moi, la meilleure des façons pour augmenter vos recettes.

• les participants : même si c’est un sujet de controverse dans de nombreuses communautés, je crois qu’il est tout à fait justifié de demander aux participants de contribuer en partie aux coûts de la conférence. Les participants profitent des installations ainsi que des événements sociaux et tirent parti de la conférence. Certaines communautés considèrent la participation à leur événement annuel comme une récompense pour services rendus ou comme une incitation à faire du bon travail dans l’année à venir. Mais je ne crois pas que ce soit une façon pérenne de voir les choses. Pour les participants à une conférence, il y a plusieurs façons de financer l’organisation de celle-ci :
  1. les droits d’inscription : c’est la méthode la plus courante pour obtenir de l’argent de la part des participants à la conférence. La plupart des conférences communautaires demandent un montant symbolique. J’ai vu des conférences qui demandaient un droit d’entrée de 20 à 50 euros ; et ça ne posait aucun problème à la plupart des gens de payer cela. Un règlement d’avance a l’avantage supplémentaire de réduire massivement les désistements parmi les gens qui vivent à proximité. Les gens accordent plus d’importance à la participation à un événement leur coûtant dix euros qu’à un autre dont l’entrée est gratuite, même si le contenu est identique,
  2. les dons : ils sont utilisés avec beaucoup de succès par le FOSDEM. Les participants reçoivent un ensemble de petits cadeaux fournis par les sponsors (livres, abonnements à des magazines, T-shirts) en échange d’un don. Mais ceux qui le souhaitent peuvent venir gratuitement,
  3. la vente de produits dérivés : votre communauté serait peut-être plus heureuse d’accueillir une conférence gratuite et de vendre des peluches, des T-shirts, des sweats à capuche, des mugs et d’autres produits dérivés afin de récolter de l’argent.? Attention ! D’après mon expérience, on peut s’attendre à obtenir moins de bénéfices de la vente de produits dérivés qu’on n’en obtiendrait en offrant un T-shirt à chaque participant ayant payé un droit d’inscription,
• les sponsors : les publications dans les médias accepteront généralement un « partenariat de presse » — en faisant de la publicité pour votre conférence dans leur magazine papier ou sur leur site Web. Si votre conférence est déclarée comme émanant d’une association à but non-lucratif pouvant accepter des dons avec des déductions d’impôts, proposez à vos partenaires dans la presse de vous facturer pour les services et de vous donner ensuite une subvention de partenariat séparée pour couvrir la facture. Le résultat final est identique pour vous. Mais il permettra à la publication de compenser l’espace qu’elle vous vend par des réductions d’impôts. Ce que vous souhaitez vraiment, ce sont des parrainages en liquide. Comme le nombre de projets de logiciels libres et les conférences se sont multipliés ces dernières années, la compétition pour les parrainages en liquide s’est intensifiée. Afin de maximiser vos chances d’atteindre le budget que vous vous êtes fixé, voici les actions que vous pouvez entreprendre :
  1. une brochure de la conférence : pensez à votre conférence comme un produit que vous vendez. Que représente-t-elle, quelle attention attire-t-elle, à quel point est-elle importante pour vous, pour vos membres, pour l’industrie et au-delà ? Qu’est ce qui a de la valeur pour votre sponsor ? Vous pouvez vendre un contrat de parrainage sur trois ou quatre éléments différents : peut-être que les participants à votre conférence constituent une audience cible de grande valeur pour le sponsor, peut-être (en particulier pour les conférences de moindre importance) que les participants ne sont pas ce qui est important mais plutôt la couverture dont bénéficiera la conférence dans la presse internationale ou bien peut-être que vous vendez à l’entreprise le fait que la conférence améliore un élément logiciel dont elle dépend. En fonction du positionnement de la conférence, vous pouvez lister les sponsors potentiels. Vous devriez avoir une brochure de parrainage que vous pourrez leur envoyer. Elle devra contenir une description de la conférence, un argumentaire de vente expliquant pourquoi il est intéressant pour l’entreprise de la parrainer, éventuellement des coupures de presse ou des citations de participants à des éditions antérieures disant à quel point votre conférence est géniale et, finalement, la somme d’argent que vous recherchez,
  2. des niveaux de parrainage : ils devraient être fixés en fonction de la somme que vous voulez lever. Vous devriez attendre de votre sponsor le plus important qu’il vous fournisse entre 30 et 40 % du budget total de la conférence, pour une conférence de moindre importance. Si vous êtes chanceux et que votre conférence attire de nombreux sponsors, cela peut s’élever à seulement 20 %. Pour vos estimations, visez un tiers. Ceci signifie que si vous avez décidé que vous avez besoin de 60 000 euros, vous devriez alors mettre votre niveau de sponsor principal à 20 000 euros et tous les autres niveaux en conséquence (disons 12 000 euros pour le deuxième niveau et 6 000 pour le troisième). Pour les conférences de moindre importance et les rencontres, le processus peut être légèrement plus informel. Mais vous devriez toujours penser au processus entier comme un argumentaire de vente,
  3. un calendrier : la plupart des entreprises ont un cycle budgétaire soit annuel, soit semestriel. Si vous émettez votre demande à la bonne personne au bon moment, vous pourriez alors avoir une discussion bien plus aisée. Le meilleur moment pour soumettre des propositions de parrainage d’une conférence estivale est aux environs d’octobre ou de novembre de l’année précédente, lorsque les entreprises finalisent leur budget annuel. Si vous manquez cette fenêtre, tout n’est pas perdu. Mais tout parrainage que vous obtenez viendra des budgets de fonctionnement qui tendent à être maigres et qui sont gardés précieusement par leurs propriétaires. Sinon, vous pouvez obtenir un engagement de parrainage en mai pour votre conférence de juin, à la fin du processus budgétaire du premier semestre — ce qui est tardif dans la préparation,
  4. approcher les bonnes personnes : je ne vais pas enseigner l’art de la vente à qui que ce soit mais mon secret personnel dans les négociations avec les grandes organisations est de devenir ami avec des personnes à l’intérieur de ces organisations et de me forger une impression sur l’origine potentielle du budget pour mon événement. Votre ami ne sera probablement pas la personne qui contrôle le budget mais l’avoir à vos cotés est une chance d’avoir un allié au sein de l’organisation. Il fera en sorte que votre proposition soit mise devant les yeux de la personne en charge du budget. Les grandes organisations peuvent être aussi dures qu’une noix est dure à craquer, mais les projets de logiciels libres ont souvent des amis dans les hautes sphères. Si vous avez vu le directeur technique ou le PDG d’une entreprise classée au Fortune 500 parler de votre projet dans un article de journal, n’hésitez pas à lui envoyer quelques mots en évoquant le fait que, quand le temps sera venu de financer cette conférence, une note personnelle demandant qui est la meilleure personne à contacter fera des merveilles. Souvenez-vous que votre objectif n’est pas de vendre votre contact personnel mais de le changer en un défenseur de votre cause à l’intérieur de l’organisation et de créer la chance de, plus tard, vendre la conférence à la personne responsable du budget,
• Souvenez-vous aussi, en vendant des contrats de parrainage, que tout ce qui vous coûte de l’argent pourrait faire partie d’un contrat de parrainage. Certaines entreprises offriront des tours de cou aux participants, la pause café, la glace de l’après-midi ou bien un événement social. Ce sont de bonnes occasions de parrainage et vous devriez exprimer clairement, dans votre brochure, tout ce qui se déroule. Vous devriez aussi définir un budget prévisionnel pour chacun de ces évènements lorsque vous écrivez le brouillon de votre budget.

3. Contenu

Le contenu d’une conférence est son élément le plus important. Des événements différents peuvent traiter différemment d’un même contenu — certains événements invitent une grande partie de leurs intervenants, tandis que d’autres comme GUADEC et OSCON font des appels à propositions et choisissent les interventions qui rempliront les salles.

La stratégie que vous choisirez dépendra beaucoup de la nature de l’événement. Si l’événement existe depuis une dizaine d’années, avec un nombre de participants toujours croissant, faire un appel à articles est une bonne idée. Si vous êtes dans votre première année, et si les personnes ne savent vraiment pas quoi faire de l’événement, alors donnez le ton en invitant de nombreux orateurs, aidant ainsi les gens à comprendre votre objectif.

Pour Ignite Lyon l’an dernier, j’ai invité environ 40 % des orateurs pour le premier soir (et j’ai souvent dû les harceler pour qu’ils me proposent une intervention). Les 60 % restants sont venus via un formulaire de candidature. Pour le premier Libre Graphics Meeting, en dehors des présentations éclairs, je pense avoir d’abord contacté chaque orateur, à l’exception de deux d’entre eux. Maintenant que l’événement en est à sa 6^e année, il existe un processus d’appel à contributions qui fonctionne plutôt bien.

4. Le programme

Il est difficile d’éviter de mettre en parallèle des exposés attrayants pour les mêmes personnes. Dans chaque conférence, vous pouvez entendre des personnes qui voulaient assister à des conférences se déroulant en même temps, sur des sujets similaires.

Ma solution pour la programmation des conférences est très simple, mais elle fonctionne dans mon cas. Des post-it de couleur, avec une couleur différente pour chaque thème, et une grille vide. Le tour est joué. Écrivez les titres des exposés (un par post-it), ajoutez les quelques contraintes que vous avez pour l’orateur, puis remplissez la grille.

Mettre le programme en-dehors de l’ordinateur, et dans des objets réels, permet de voir très facilement les conflits, d’échanger les conférences aussi souvent que vous voulez, et de le publier ensuite sur une page Web quand vous en êtes satisfait.

J’ai utilisé cette technique avec succès pour GUADEC 2006 et Ross Burton l’a réutilisée avec succès en 2007

.

5. Les fêtes

Les fêtes sont un compromis à trouver. Vous voulez que tout le monde s’amuse, et s’éclater jusqu’au petit matin est une partie très importante quand on participe à une conférence. Mais la fréquentation matinale souffre après une fête. Ayez pitié du pauvre membre de la communauté devant se tirer hors du lit après trois heures de sommeil pour aller parler devant quatre personnes à 9 heures du matin après la fête.

Certaines conférences ont trop de fêtes. C’est super d’avoir la possibilité de se saouler avec des amis chaque nuit. Mais ça n’est pas génial de vraiment le faire chaque nuit. Rappelez-vous du but de la conférence : vous voulez stimuler l’avancement de votre projet.

Je préconise une grande fête, et une plus petite, au cours de la semaine. En-dehors de ça, les personnes seront tout de même ensemble et passeront de bons moments, mais ce sera à leurs frais, ce qui fait que chacun restera raisonnable.

Avec un peu d’imagination, vous pouvez organiser des événements qui n’impliquent pas l’utilisation de musique forte et d’alcool. D’autres genres d’événements sociaux peuvent faire l’affaire, et même être plus amusants.

Au GUADEC, nous organisons un tournoi de football depuis quelques années. Lors du sommet OpenWengo en 2007, nous avions embarqué les personnes pour une balade en bateau sur la Seine puis nous étions ensuite montés sur un manège du XIX^e siècle. Faire manger les gens ensemble est un autre moyen de nouer des liens. J’ai de très agréables souvenirs de repas de groupe lors de nombreuses conférences. À la conférence annuelle de KDE, l’Akademy, il y a traditionnellement une grande journée de sortie durant laquelle les personnes vont ensemble à un pique-nique, quelques activités simples de plein air, une promenade en bateau, un peu de tourisme ou quelque chose de similaire.

6. Les coûts supplémentaires

Attention à ces dépenses imprévues ! Une conférence dans laquelle j’étais impliqué, et où le lieu de réunion était « sponsorisé à 100 % » nous a laissé une note de 20 000 euros pour les coûts de main-d’œuvre et d’équipement. Oui, le lieu était sponsorisé, mais la mise en place des tables et des chaises, ainsi que la location des écrans, des vidéoprojecteurs et de tout le reste ne l’était pas. Au bout du compte, j’ai estimé que nous avions utilisé seulement 60 % de l’équipement que nous avions payé.

Tout ce qui est fourni sur place est extrêmement coûteux. Une pause-café peut coûter jusqu’à 8 euros par personne pour un café et quelques biscuits, de l’eau en bouteille pour les conférenciers coûte quatre euros par bouteille, etc. La location d’un rétroprojecteur et de micros pour une salle peut coûter 300 euros ou plus pour une journée, selon que le propriétaire exige ou non que l’équipement audio-vidéo soit manipulé par son propre technicien.

Quand vous traitez avec un lieu commercial, soyez clair dès le départ sur ce pour quoi vous payez.

Les détails sur place

J’aime les conférences attentives aux petits détails. En tant qu’orateur, j’aime quand quelqu’un me contacte avant la conférence pour m’avertir qu’il me présentera. Que souhaiterais-je qu’il dise ? C’est rassurant de savoir que, quand j’arriverai, il y aura un micro sans fil et quelqu’un qui peut aider à l’ajuster.

Faire attention à tous ces détails nécessite de nombreux volontaires, et ça nécessite quelqu’un pour les organiser avant et pendant l’événement. Il faut passer beaucoup de temps à parler à l’équipe sur place, plus particulièrement aux techniciens audio/vidéo.

Lors d’une conférence, le technicien audio-vidéo avait prévu de basculer manuellement l’affichage vers un économiseur d’écran à la fin d’une conférence. Au cours d’une session de mini-conférences, nous nous sommes retrouvés dans une situation burlesque quand, après le premier conférencier, j’ai interverti l’ordre de passage : au moment où la présentation suivante s’affichait sur mon portable, nous avions toujours l’économiseur sur le grand écran. Personne n’avait parlé avec le technicien de la régie pour lui expliquer le format de la présentation ! Et c’est comme ça qu’on a fini par avoir pas moins de quatre spécialistes de Linux à s’occuper de l’ordinateur portable qui vérifiaient les connexions en psalmodiant divers mantras Xrandr, qui s’efforçaient de remettre en marche le rétroprojecteur au-dessus de nos têtes ! Nous avons fini par changer d’ordinateur portable, le technicien de la régie a compris de quel type de session il s’agissait, et ensuite tout s’est fort bien passé — la plupart des gens concernés ont accusé mon portable.

Gérer une conférence, ou parfois une plus petite rencontre, prend du temps, et nécessite beaucoup d’attention aux détails, qui pour la plupart ne seront jamais remarqués par les participants. Et je n’ai même pas évoqué des choses comme les banderoles et les affiches, la création du graphisme, la gestion de la presse ou d’autres joyeusetés qui vont de pair avec l’organisation d’une conférence.

Le résultat final est en revanche particulièrement gratifiant. Une étude que j’ai menée l’année dernière sur le projet GNOME a montré qu’il y a eu une forte augmentation de la productivité sur tout le projet juste après notre conférence annuelle et un grand nombre de membres de notre communauté mentionnent la conférence comme ayant été, pour eux, le point culminant de l’année.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Ouve, Julius22, Sphinx, fubik, peupleLà, goofy, KoS, merlin8282, Munrek, Asta, Jej, Alpha, lamessen

L’important, c’est les gens

Nóirín Plunkett

Nóirín Plunkett est une touche-à-tout qui maîtrise plusieurs domaines. Rédactrice technique le jour, son travail open source illustre l’expression « Si vous voulez que quelque chose soit fait, demandez à une personne occupée ». Nóirín a commencé dans l’open source avec Apache, donnant un coup de main sur la documentation du projet httpd. En moins d’un an, elle a été recrutée dans l’équipe de planification des conférences, qu’elle dirige désormais. Elle a participé à la mise en place du projet de développement communautaire chez Apache et a déjà agi en tant qu’administratrice d’organisation pour le Summer of Code. Elle siège aux conseils d’administration de la fondation du logiciel Apache et de l’Initiative Open Cloud. Quand elle n’est pas en ligne, elle est dans son élément naturel sur une piste de danse. Mais c’est également une harpiste et chanteuse talentueuse et une excellente sous-chef (NdT : en français dans le texte).

Rien ne vaut une voie classique, bien que la mienne le soit peut-être moins que la plupart des autres. J’ai fait ma première contribution quand j’avais la vingtaine. À cette époque, j’avais déjà travaillé plus d’un an chez Microsoft. Mais après Microsoft, j’ai déménagé à l’étranger afin de poursuivre mes études. C’était sympathique d’avoir un divertissement, j’ai donc commencé à travailler sur différentes documentations et traductions et j’ai contribué au projet httpd d’Apache.

Comme par hasard, bien sûr, la conférence européenne sur Apache allait avoir lieu à Dublin, alors que, cet été-là, j’étudiais à Munich. Mais la chance sourit aux Irlandais et, avec un peu d’astuce, j’ai convaincu Sun Microsystems de financer ma participation à la conférence.

J’ai une photo du moment où j’ai pris conscience que cette chose appelée open source était bien réelle, et que ça allait changer le monde. C’était pendant la soirée avant la conférence. Nous n’avions toujours pas trouvé où la fibre se terminait, elle était censée constituer la colonne vertébrale de notre réseau. Nous avions vérifié chaque coin, chaque armoire et chaque plinthe, en vain. Nous avions laissé tomber pour cette nuit, et nous étions occupés à nous assurer que les salles qui accueilleraient les sessions de formation auraient au moins suffisamment de connectivité pour que les formateurs puissent utiliser leurs supports de présentation (1).

Et à mesure que la nuit tombait, que les routeurs révélaient lentement les secrets de leurs configurations par défaut, la demi-douzaine de volontaires, des gens que je n’avais rencontrés que dans l’après-midi même, devenaient des amis.

Je ne pourrais pas vous dire où sont les six filles avec lesquelles j’ai vécu pendant cet été-là à Munich. Mais je suis toujours en contact avec chacune des personnes que vous voyez sur cette photo. L’une d’elles a déménagé dans un autre pays, une autre est partie sur un autre continent. La plupart ont changé de travail entre-temps, j’ai eu mon diplôme et je me suis conformée à la grande tradition irlandaise de l’émigration pour trouver du travail.

Vous voyez, l’open source, c’est d’abord des gens. Vraiment, sur presque n’importe quel projet dont vous voudriez faire partie, le code ne vient qu’après.

Ce qui fait que travailler sur un projet est un bonheur et non une plaie, ce sont les gens. Ce qui fait qu’un projet prospère plutôt qu’il ne stagne, ce sont les gens. Bien entendu, vous serez capable de coder toute la nuit pour un projet si ça permet de résoudre un problème que vous pensez être important ; mais, à moins d’avoir des gens avec lesquels vous pouvez collaborer, discuter, concevoir et développer, vous allez probablement finir par perdre la motivation ou vous retrouver bloqué pour un bout de temps.

Les conférences, les sprints, les hackathons, les « retraites » (NdT : une ou plusieurs journées qui se concentrent sur la création de code de très bonne qualité plutôt qu’écrit dans l’urgence) ou tout ce que votre communauté appelle ses « moments de face à face », voilà leur vraie valeur : permettre de se retrouver face à face avec les gens avec lesquels vous avez travaillé. Les êtres humains sont des animaux sociaux ; les bébés reconnaissent des visages avant même de commencer à gazouiller, et peu importe à quel point les gens sont polis ou amicaux dans leurs courriels, il y a toujours quelque chose qui manque dans ces communications-là.

Rencontrer des gens en face à face nous donne une occasion de voir l’humanité de ceux avec qui on a pu avoir du mal à s’entendre, de partager la joie du travail bien fait avec ceux avec qui on aime travailler. Ainsi, si j’avais un conseil à donner à ceux qui commencent, et j’aurais aimé qu’on me le donne, ça serait de sortir, de rencontrer des gens, de coller des noms aux visages dès que l’opportunité se présente (2).

Et si vous trouvez que les occasions sont rares et trop espacées, n’hésitez pas à demander. Cherchez des gens qui voyagent près de chez vous ou qui vivent là où vous voyagez, dénichez un parrainage pour assister aux grands événements de la communauté, organisez votre propre événement !

C’est la richesse de nos communautés qui donne toute sa valeur à l’open source, ainsi que les efforts partagés vers des objectifs communs. Et, bien sûr, les sessions musique, les repas, les pintes et les soirées ! Ce sont les choses qui nous rassemblent, et vous allez découvrir qu’une fois que vous avez rencontré les gens en personne, même vos interactions par courriel seront plus riches, plus gratifiantes et plus fructueuses qu’elles ne l’étaient auparavant.

——————————————————————

Notes de l’auteur :

(1) Le lendemain matin, nous sommes allés dans les combles pour essayer de trouver la fibre, toujours rien. Pour finir, nous l’avons trouvée dans le local technique de la boîte de nuit, située dans le sous-sol à côté.

(2) Malheureusement, je dis ça comme une mise en garde : comme dans tout rassemblement important, assister à une conférence open source présente des risques. Certains pires que d’autres, mais d’après mon expérience, les agressions, particulièrement, semblent plus fréquentes dans les communautés techniques que dans les communautés non-techniques. Dénichez les événements qui publient un code de conduite ou une politique anti-harcèlement et demandez de l’aide si vous ne vous sentez pas en sécurité. La grande majorité des gens que vous trouverez dans un événement open source sont des êtres humains formidables et attentionnés. J’espère qu’avec le temps, changer les attitudes empêchera la minorité de penser qu’elle peut se permettre des comportements déraisonnables dans ce genre de lieux…

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang :Julius22, Sphinx, fubik, peupleLà, okram, goofy, merlin8282, Munrek, Texmix, Asta, Jej, gregseth, lamessen

Qui êtes-vous, qu’avez-vous à vendre et en quoi ça pourrait m’intéresser ?

Sally Khudairi

Active sur le Web depuis 1993, Sally Khudairi est la publicitaire en embuscade derrière certaines des organisations et des standards les plus importants de cette industrie. Ancienne adjointe de Sir Tim Berners-Lee et championne toutes catégories de l’innovation collaborative, elle a aidé au lancement de The Apache Software Foundation en 1999 et en fut la première femme et membre non-technique élue. Sally est vice-présidente du marketing et de la publicité pour The Apache Software Foundation et directrice générale de HALO Worldwide, une société de conseil en communication pour des marques de luxe.

Tout le monde est vendeur. Du PDG à la star des commerciaux, en passant par le gars qui répartit le courrier, chacun est un représentant de votre entreprise. Les technologies et les stratégies ont changé au fil des années mais une bonne communication reste primordiale. Au bout du compte, tout le monde vend quelque chose, et c’est un équilibre intéressant à trouver dans la publicité ; qui vous êtes, ce que vous faites et ce que vous vendez sont souvent étroitement imbriqués. Quand les gens me disent qu’ils ne savent pas qui je suis, je leur demande s’ils ont entendu parler du W3C, d’Apache ou des Creative Commons.

La réponse habituelle est « bien sûr ! », ce qui me confirme que je fais bien mon boulot. Si vous savez qui ils sont et ce qu’ils font, tout va bien. Après tout, c’est le produit qui compte, pas le publicitaire. Je n’ai jamais cherché à être là : me faire les dents dans la communication à la naissance du Web n’était pas facile, mais grâce au ciel j’ai pu observer les autres et esquiver un certain nombre de torpilles. Après une forte montée en puissance et quelques projets très en vue, quel conseil pourrais-je partager avec un chargé de relations publiques en herbe, avec un porte-parole chevronné rompu à la pratique des médias, ou un technologue qui ose enfourcher le cheval ombrageux de la promotion, malgré ses ruades ?

N’oubliez jamais de vous manifester

Quand vous vendez votre histoire à la presse, souvenez-vous que les médias, eux aussi, ont quelque chose à vendre. Bien sûr, au plus haut niveau, le rôle d’un journaliste est de raconter une histoire irrésistible et convaincante — qu’elle soit vraie ou non, que les faits soient exacts ou non —, qu’elle réponde ou non à une éthique, c’est une autre question. Qu’il s’agisse d’attirer le lectorat, de fidéliser les abonnés ou de promouvoir les espaces publicitaires, eux aussi sont en train de vendre quelque chose. Votre boulot, c’est de les aider à faire le leur. À dire vrai, il est possible que certaines personnes n’aient jamais entendu parler de vous, même si vous êtes dans le métier depuis déjà pas mal de temps. Même si ce n’est pas le cas, ils peuvent ne pas savoir exactement qui vous êtes. Soyez clair sur ce que vous avez à offrir. Quelle est l’accroche pour la presse — quelle est la nouvelle ? Assurez-vous qu’elle est vraiment nouvelle. Soyez direct et venez-en rapidement au fait. Vous devez être prêt à répondre aux questions suivantes : « et alors ? », « En quoi ça pourrait m’intéresser ? » et « Qu’est-ce qu’il y a là-dedans pour moi ? ». Cela veut dire que vous devez vous poser des questions sur vous-même et sur votre produit. Les gens achètent des idées, pas des produits. Faire la promotion des avantages de ce que vous lancez vous aidera à améliorer vos chances d’obtenir une couverture médiatique. Faites un pas de côté : qu’êtes-vous vraiment en train de vendre ?

Jamais le vendredi

Le pire des jours pour lancer un nouveau site web, diffuser un communiqué de presse ou informer les médias, c’est le vendredi. La probabilité qu’il se passe quelque chose et que personne ne soit disponible pour gérer les retombées est plus importante que vous ne pouvez l’imaginer. J’en ai eu une cuisante expérience dès le début de ma carrière. J’avais lancé la nouvelle page d’accueil du W3C un vendredi soir puis quitté le bureau et embarqué dans un avion pour Paris. Comme je venais du monde de la publication commerciale sur Internet, utiliser un tag propriétaire ne me posait aucun problème à partir du moment où il faisait le travail. Faire de même sur le site internet d’une organisation vouée à l’interopérabilité, en revanche, n’était pas une bonne idée. En quelques minutes, des douzaines de messages arrivèrent, demandant comment la <balise-aujourd’hui-dépréciée> était arrivée sur notre site. Et non, ça n’était pas <blink>…

N’imaginez jamais que cela n’a aucune importance

La crédibilité est essentielle. Même si vous êtes surchargé de travail, dévoué corps et âme ou partout à la fois, vous ne pouvez pas empêcher l’heure de sonner. Essayez de produire autant que vos capacités vous le permettent et demandez de l’aide si vous le pouvez. Certaines échéances doivent être négociées, et beaucoup d’éditeurs peuvent s’accommoder d’un retard dans le calendrier mais cela n’aura probablement pas (autant) d’importance une fois l’urgence passée si vous n’êtes pas capable de finir le travail. Tout comme pour l’art, le développement de standards et la relecture-correction, le processus peut se poursuivre et recommencer ad nauseam. Tandis que la créativité ne peut pas être gérée par le temps, des dates butoir strictes obligent à tracer une limite à un moment donné. Mais vous devez vous soucier des détails. Arrêtez-vous. Révisez tout et testez tous les liens. Assurez-vous que cela correspond parfaitement à la stratégie de la campagne ou de la marque. Les cycles de répétition font partie des grands principes structurants de la communication et le travail continuera à s’accumuler. Organisez-le et protégez votre réputation.

Allez-y seul

Il est important d’avoir confiance en vos instincts, spécialement lorsque vous sortez des sentiers battus. Aux premiers jours du Web supercool et ultramoderne, tout le monde semblait s’en remettre aux stratégies habituelles des marques/relations publiques/marketing qui consistaient à faire des sites vitrines. Puis tout le monde « suivait le meneur » (le meneur est « le premier à l’avoir fait », dans de nombreux cas). Les tendances sont une chose, les attentes et les besoins de l’industrie en sont une autre : « c’est comme ça que tout le monde fait » ne veut pas dire que c’est bien pour vous, votre projet ou votre communauté. Ma carrière dans la communication a commencé lorsque j’ai renvoyé le sous-traitant que nous avions choisi et tout ramené en interne.

Nous avons été parmi les premières organisations à mettre une adresse URL sur notre plaquette commerciale, et nous avons été les premiers à utiliser une URL comme source d’un communiqué de presse alors que les agences de presse nous disaient que cela n’était pas conforme et contraire aux règles. Faites confiance à vos connaissances. Allez à contre-courant et bousculez les règles de manière responsable. Sachez vous différencier. Il est permis d’être un dissident tant que vous pouvez soutenir vos idées.

Offrez vraiment des perspectives

Bon nombre des technologies dans lesquelles je suis impliquée finissent en produits au bout de trois à cinq ans. Ceci signifie que, dans bien des cas, il est difficile d’établir une quelconque relation à un produit comparable. Il est crucial que vous expliquiez clairement votre position en utilisant le moins de jargon possible. La plupart des journalistes et analystes non-développeurs avec lesquels je suis en contact ne suivent pas les activités d’une certaine communauté au quotidien et ne savent pourquoi telle fonctionnalité est meilleure qu’une autre, même si c’est une évidence pour vous.

Dire qu’on va « privilégier la forme plutôt que le fond » est plus pertinent aujourd’hui que jamais. Forme. Fond. Je marque toujours une séparation à ce sujet lorsque je fais de la formation aux médias : présentez trop le fond ou trop la forme et votre campagne risque d’échouer. La perception est fondamentale et la cause de bien des conflits. Tout sur la forme = « branché + hyperbole » = « Ah, ces marketeux ! ». Tout sur le fond = « des zéros et des uns » = « Ah, ces geeks ! ».

Il vous faut comprendre et pouvoir expliquer clairement quel est le problème que résout votre produit. En sachant mieux présenter le problème, vous pourrez mieux en expliquer la solution. Les détails accessoires, les anecdotes et les succès, voilà ce qui donne à la presse un moyen d’attirer l’attention de son lectorat. Vous devez savoir répondre à la question « Qu’y a-t-il pour moi là-dedans ? », parce que c’est ce qui incite les journalistes à fouiller un peu plus dans votre histoire, qui, en retour, permet aux lecteurs d’en savoir plus sur vous. La forme répond à la question « Qu’y a-t-il pour moi là-dedans ? », c’est donc l’hameçon. Le fond est le comment on y parvient.

Ayez des porte-parole sur la brèche

Ayez toujours quelqu’un de disponible pour parler à la presse. Oui, ça peut être vous, mais sachez qu’il y aura un moment où, même si vous avez une histoire bien planifiée à raconter, vous pourriez ne pas être disponible. Avec qui d’autre travaillez-vous ? Qui vous connaît ? Qui vous soutient ? Définir ces personnes et distribuer les rôles pour clarifier qui dit quoi contribue beaucoup à diminuer les maux de tête potentiels. J’agis habituellement en tant que porte-parole d’arrière-plan afin de pouvoir passer du temps avec un journaliste pour trouver ce qu’il recherche spécifiquement et comment nous pouvons lui donner les informations pertinentes du mieux possible.

J’explique comment les choses fonctionnent, principalement sur les processus ; cela met mes « vrais » porte-parole en meilleure position pour dire quels sont leurs besoins et minimise le risque de perdre leur participation en chemin. Préparer les bonnes personnes est aussi important que de les rendre disponibles. Pendant mes cours de formation aux médias, je mets quelques diapositives « surprenantes » qui soulignent les leçons particulièrement intéressantes apprises au fil des ans.

Nous avons par exemple connu une pagaille de représentants dans les premiers jours de l’incubateur Apache, où 15 personnes ont répondu à une demande de la presse en 48 heures… beaucoup d’opinions, mais qui était la « bonne » personne à citer ? Ne laissez pas la presse en décider ! Un autre scénario suprenant comprenait une fête de lancement globale avec des centaines d’invités, des représentants de la presse partout, des DJ, de la musique à fond, des cocktails à flot, et tout ça durerait jusqu’à très tard dans la nuit avec des rumeurs de soirées en after.

Très tôt le matin suivant, la presse a débarqué (oui, bien sûr, j’accepte les appels du Financial Times à quatre heures du matin !). J’ai accepté avec excitation. Cependant, il s’avéra que nous n’avions pas de représentant disponible : le président était dans un avion à destination du Japon, le téléphone portable du directeur était éteint (avec une bonne raison, apparemment) ; les membres du conseil d’administration indisponibles, l’équipe non préparée. Des dizaines d’occasions manquées. Rappelez-vous : quand le communiqué de presse est diffusé, le travail commence tout juste.

Ne soyez pas surpris de le voir affluer de partout

Ils ont tous un avis. Et ils vont probablement vous le donner.

Ne compliquez pas les choses à outrance

Si vous pensez que vous avez trop de choses à dire, c’est probablement le cas. Les facultés d’attention ne sont plus ce qu’elles étaient ; la distraction/l’échec est à portée de clic. Rappelez-vous que vous pouvez toujours travailler par étapes. Décomposez votre histoire si nécessaire. Coupez un long communiqué de presse et utilisez des supports documentaires comme des fiches de description technique et des pages de témoignages à la place. Le principe de segmentation (« cinq plus ou moins deux ») est quelque chose que j’utilise encore et encore. Créez votre propre cycle de publication pour vos messages et renforcez régulièrement votre présence. Créez une FAQ ; si une question mérite d’être posée et n’y est pas, trouvez le moyen de compléter votre message. La répétion engendre la familiarité. Le renforcement progressif de votre appel à l’action est une bonne chose.

N’y touchez plus pendant 24 heures

Parfois, vous avez besoin de prendre du champ. Vous éloigner d’un projet, d’un raisonnement, du travail en général. Accordez-vous une pause et essayez de garder un certain rythme. Prenez une journée pour laisser décanter et vous permettre de souffler. Bien que ce ne soit pas possible dans une entreprise gouvernée par les dates butoir, c’est un but à viser. La course effrénée, les courriels incessants et les tweets en continu déclenchent souvent des réactions à des urgences qui n’existent pas. Laissez le projet de côté, videz-vous la tête et revenez avec des idées claires. Faites un pas de côté et reprenez votre vie en main.

Visez haut

Placez haut la barre et soyez conscient de votre valeur.

Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Ouve, merlin8282, Julius22, fubik, lamessen, okram, goofy, Munrek, Asta, Jej, Alpha

Les projets trop ambitieux échouent

Jos Poortvliet

Jos Poortvliet travaille en tant que gestionnaire de communauté pour SUSE Linux. Auparavant, il était actif dans la communauté KDE internationale en tant que responsable de l’équipe marketing. Dans sa « vie hors-ligne », il a travaillé dans différentes entreprises en tant que conseiller en stratégie d’entreprise. Il passe son temps libre à expérimenter dans sa cuisine, où il tente de parvenir à quelque chose de comestible.

« Mieux vaut faire beaucoup de petits pas dans la bonne direction qu’un grand bond en avant pour retomber en arrière. » (Vieux proverbe chinois)

Une idée géniale…

Il était une fois, au sein de l’équipe marketing d’un projet de logiciel libre, quelqu’un qui eut une idée géniale pour faire se développer le projet. Un programme serait mis en place pour permettre à des étudiants en informatique de prendre connaissance du projet et de le rejoindre. Des universités seraient contactées et quelqu’un s’adresserait à elles pour susciter leur intérêt. Des ambassadeurs iraient alors dans ces universités pour y donner des cours et encadrer les premiers pas des étudiants dans le monde du logiciel libre. Une fois qu’ils auraient rejoint le projet en ligne, ils seraient encadrés sur des tâches simples et deviendraient finalement des contributeurs chevronnés ! Les universités adoreraient ce programme, bien sûr, et, avec un peu de chance, commenceraient à participer plus activement, en donnant à leurs étudiants du code à écrire pour le projet et bien plus encore.

… qui n’a pas fonctionné…

J’ai vu l’idée développée dans la fiction ci-dessus sous bien des formes dans de nombreuses communautés et projets. C’est une idée géniale et d’un fort potentiel ! Nous savons tous qu’il faut commencer tôt — nos concurrents du logiciel propriétaire sont très bons pour ça. Nous savons également que nous disposons de suffisamment d’arguments pour convaincre les universités et les étudiants de participer — le logiciel libre et open source représente le futur, il offre de très belles possibilités de développement des compétences. Les compétences en programmation ou en administration sous Linux sont davantage demandées que des développeurs Java ou .NET ou que des administrateurs système Windows. Et surtout : c’est plus amusant. Quoi qu’il en soit, si vous allez dans des universités, vous ne verrez pas beaucoup d’affiches vous invitant à rejoindre des projets de logiciels libres. La plupart des professeurs n’en ont jamais entendu parler. Que s’est-il passé ? Permettez-moi de continuer mon histoire.

… pas à cause d’un manque d’efforts…

L’équipe en a discuté longtemps. D’abord en mettant des idées en commun — de nombreuses idées concernant la concrétisation du concept ont fusé. Le responsable de l’équipe les a rassemblées et mises sur le wiki. Un calendrier a été établi avec des échéances et le responsable a réparti les tâches, pour certaines parties. Certains ont commencé à rédiger des supports de cours, d’autres à lister les références des universités. Ils ont régulièrement demandé des suggestions et des idées sur la liste de diffusion et ont reçu beaucoup de réponses proposant d’autres supports de cours, que le responsable a ajoutés à la liste des choses à rédiger. Tout devait être fait pendant le temps libre des volontaires, mais on pouvait toujours compter sur le responsable pour rappeler les échéances aux volontaires.

Après quelques mois, une structure était visible et de nombreuses pages étaient créées sur le wiki.

Entre-temps, néanmoins, le nombre de personnes impliquées depuis la discussion initiale a diminué, passant de plus de 30 à environ cinq qui faisaient encore mine de travailler. Le responsable a décidé de revoir la feuille de route avec des dates butoirs et, après quelques appels lancés sur la liste de diffusion, 10 nouveaux volontaires s’engagèrent à réaliser diverses tâches. Le rythme s’est à nouveau un peu accéléré. Un certain nombre de choses qui avaient déjà été faites ont dû être mises à jour et il y avait d’autres ajustements à faire. Malheureusement, les choses ont continué à s’aggraver et le nombre de personnes impliquées a continué à diminuer. Des sprints mensuels furent mis en place, et ils ont en effet abouti à terminer davantage de choses. Mais il y avait simplement trop à faire. Au bout d’environ un an, les dernières personnes ont jeté l’éponge. Il n’en reste qu’une page wiki obsolète et quelques ressources dépassées…

… mais parce qu’elle était trop ambitieuse

Alors pourquoi ça n’a pas marché ? L’équipe avait pourtant appliqué les meilleures techniques de gestion de projet qu’il est possible de trouver sur le Web : brainstorming, puis mise en place d’un planning avec un échéancier, des objectifs précis ainsi que des responsabilités. Ils ont fait ce qu’il fallait faire sur un projet bénévole : solliciter les personnes, les impliquer, donner la possibilité à chacun d’exprimer son opinion. Ça aurait dû fonctionner !

Ce ne fut pas le cas pour une raison simple : c’était trop ambitieux. C’est une tendance. Des idées géniales reçoivent beaucoup de commentaires, sont inscrites dans de grands plannings qui se terminent en pages wiki incomplètes amenant à une faible implémentation qui finit par s’évanouir dans le néant.

Les responsables doivent admettre que la manière de travailler d’une équipe dans le domaine du logiciel libre et open source n’est pas la même que dans un environnement structuré et dirigé comme peut l’être une entreprise. Les gens ont tendance à être présents lorsque quelque chose d’excitant se produit, comme lors de la sortie d’une version majeure, puis à disparaître jusqu’au prochain gros événement. La création d’une équipe communautaire ne devrait jamais supposer que les gens resteront pleinement impliqués jusqu’à la fin. Il faut prendre en compte le fait qu’ils seront présents pendant un certain temps, puis s’absenteront durant de plus longues périodes avant de revenir. Les arrivées et les départs font qu’il y a beaucoup d’agitation superflue et que le travail avance lentement. Oui, il est possible de diriger des gens, mais il n’est pas possible de les gérer. Dès que vous apprenez à laisser l’aspect gestion de côté, vous pouvez davantage vous concentrer sur les choses à faire dans les plus brefs délais.

Ainsi, au lieu de prévoir les grandes étapes, trouvez quelque chose de plus modeste qui soit réalisable et utile en soi. Non pas une page wiki avec un planning, mais la première étape de ce que vous voulez accomplir. Et ensuite donnez l’impulsion en faisant les choses. Faites le premier brouillon d’un article. Créez la première version d’un dossier. Copiez-collez à partir de n’importe quoi d’existant ou améliorez quelque chose qui existe déjà. Ensuite, présentez le résultat à l’équipe, aussi brouillon qu’il puisse être, et demandez si quelqu’un souhaite l’améliorer. Faites une petite chose et ça fonctionnera.

Ne planifiez pas, agissez…

Comment alors allez-vous réaliser quelque chose d’aussi énorme qu’un programme de recrutement des étudiants avec le concours des universités ? Ne le faites pas ! Du moins, pas directement. Il faut en discuter avec toute l’équipe et le planifier — ça donnera certainement lieu à une discussion sympathique pouvant durer des semaines. Mais ça ne vous mènera pas loin. Gardez plutôt le plan pour vous-même. Sérieusement.

Je ne suis pas en train de dire qu’il ne faudrait pas en parler — vous le pouvez. Faites part de votre ambitieux projet à tous ceux qui sont intéressés. Et c’est tant mieux s’ils font des propositions. Mais n’en attendez pas trop, ne faites pas de plans au-delà de la première ou des deux premières étapes. Allez plutôt de l’avant, construisez sur ce qui existe déjà. Envoyez le brouillon d’un support de communication fraîchement créé ou amélioré à la liste de diffusion. Demandez à quelqu’un ayant donné un cours sur votre projet de partager son support et améliorez-le un peu. Qui sait, les personnes dont le travail vous sert de base pourraient vous venir en aide ! Les gens avec qui vous avez discuté de votre projet et qui partagent votre vision pourraient également vous aider. De cette façon, vous terminerez souvent quelque chose — un prospectus, un site web amélioré ou une présentation utilisable. Et les gens peuvent, peu à peu, commencer à les utiliser. Des ambassadeurs peuvent se rendre dans leur université et utilisant une des choses que vous avez déjà créées. Pour cela, ils auront certainement besoin de créer des éléments manquants — qui pourront ensuite se retrouver sur le wiki. Et vous progressez.

… et vous aurez votre château en Espagne !

En marketing communautaire, la bonne stratégie ne réside pas dans le wiki. Elle ne dépend pas d’un programme ni d’un planning. Elle n’est pas non plus discutée chaque semaine avec l’équipe complète. Elle fait partie d’une vision qui s’est développée au cours du temps. Elle est portée par quelques personnes-clés qui indiquent le planning à court terme ainsi que les objectifs et elle est partagée par l’équipe. Mais elle n’a pas de date butoir ni de risque d’échouer. Elle est flexible et ne dépend de rien ni de personne en particulier. Et ça restera toujours un château en Espagne…

En conséquence, si vous voulez piloter un effort marketing pour une communauté de logiciel libre, faites en sorte que la vision d’ensemble reste une vision d’ensemble. Ne planifiez pas trop, mais faites en sorte que des choses se réalisent !