Cookies verzekeren het goed functionneren van onze website. Door gebruik te maken van deze site, gaat u akkoord met ons gebruik van cookies. Meer informatie OK
U bent hier: Home / Blog

Blog

Moi, je suis très "people"

Un vrai partenariat

PPPP : Public-Private-People partnership. Rebondissant sur le dernier blogpost de François Lambert, publié ici-même la semaine dernière, il m’a paru intéressant de vous présenter la manière dont le CIRB envisageait de mieux intégrer dans ses projets ces partenaires que sont les habitants de la Région Bruxelloise.

Citoyens ? Partenaires ? Oui, même si la mission première du CIRB est de répondre aux besoins des institutions publiques bruxelloises, nous ne devons pas oublier que ces mêmes services publics sont là pour aider les citoyens… ou, à tout le moins, de ne pas leur compliquer la tâche. Extrapolant cette réflexion, un projet de smart city nécessite aussi, à mon sens, l’évolution de la manière dont nous intégrons les services des entreprises privées.

Un petit pas vers les citoyens

A l’heure actuelle, le site http://smartcity.brussels est, à ma connaissance, une des seules initiatives concrètes qui s’adresse directement aux habitants de la Région de Bruxelles-Capitale au sujet des projets IT. En ligne depuis quelques mois, ce site présente les projets smart déjà en cours et vous permet, par exemple de donner votre préférence pour les prochains lieux de déploiement d’antennes Wi-Fi, de voter pour votre projet smart favori ou de faire de nouvelles propositions.

Mais d’autres pistes sont envisagées. La première consisterait à faire tester l’ergonomie de nos applications par des citoyens. Nous pensons ici directement au guichet électronique IRISbox accessible 24h sur 24 et 7 jours 7 et donnant accès à des formulaires interactifs pour l’obtention de documents administratifs (extraits d'acte ou de casier judiciaire, certificats de vie, de composition de ménage, réservation de voirie, carte de riverain/stationnement, etc.). Cette plateforme est en ligne depuis de nombreuses années mais l’avis direct de nos concitoyens nous permettrait de prendre en compte leurs suggestions d’amélioration.

Dans le même ordre d’idée, nous pourrions aussi consulter les citoyens sur les évolutions futures de ces plateformes et ce, afin d’étendre la gamme de services déjà proposée. On appelle cela la cocréation, considérée comme un mécanisme permettant l’innovation et la transformation. Ce concept existe depuis une dizaine d’années mais est aujourd’hui très à la mode. Si participer à ce genre de test ou de consultation vous intéresse, n’hésitez pas à me le faire savoir.

Impliquer le privé

La cocréation peut se faire aussi avec les entreprises privées. Dans ce cas, les difficultés sont d’un autre ordre. En effet, nous ne pouvons pas à la fois demander le concours de sociétés privées pour innover et, en même temps, ne pas les rétribuer pour les services fournis. Or, en tant qu’entreprise publique, le CIRB est soumis aux lois sur les marchés publics. Marchés publics qui nécessitent des cahiers des charges précis…pas toujours compatibles avec la recherche et l’innovation. D’autres mécanismes doivent être mis en place.

A l’heure actuelle, l’approche la plus classique consiste à créer des partenariats publics-privés pour répondre à des appels d’offres européens. Ce genre de projet permet à une ville de tester des solutions innovantes en limitant les coûts de projet. De son côté, l’entreprise privée est effectivement payée pour ses prestations. Le site https://eu-smartcities.eu/ recense ces initiatives à travers l’Europe. De tels projets sont en cours dans notre Région et le CIRB est lui-même impliqué dans plusieurs d’entre eux (ECIM, C3PO).

Mais il existe d’autres voies pour susciter l’innovation. Pas plus tard qu’hier, j’apprenais l’existence des marchés publics innovants. Je n’ai pas encore approfondi le sujet, mais il semblerait que ce soit aussi une piste pour avancer vers plus de smart city. Comme signalé plus haut, la loi sur les marchés publics amène parfois à des contraintes extrêmement rigides qui ne permettent pas vraiment l’innovation, c’est-à-dire le tâtonnement. La législation européenne semble avoir évolué pour permettre une plus grande prise de risque dans les projets pour lesquels il n’existe pas encore de solutions. La France, par exemple, intègre déjà ce type de mécanisme et oblige les administrations à l’utiliser. Je cite : « Le Pacte national pour la croissance, la compétitivité et l’emploi a entendu faire de la commande publique un levier au soutien de la capacité d’innovation des entreprises. La mesure 32 de ce Pacte exige ainsi qu'au moins 2% de la commande  publique de l’Etat, de ses opérateurs et des hôpitaux soient effectués auprès des petites et moyennes entreprises (PME) et entreprises de taille intermédiaires (ETI) de croissance innovantes à l’horizon 2020 ».

A titre personnel, je trouverais aussi intéressant que les nouveaux projets urbanistiques à Bruxelles intègrent, dès leur conception, les infrastructures nécessaires au déploiement de solutions intelligentes et puissent servir de véritables living labs, laboratoires grandeur nature permettant de tester des solutions innovantes. Là aussi, les exemples sont nombreux à travers le monde. Vous pouvez en prendre connaissance via le site de l’European Network of Living Labs.

Mais terminons ce tour d’horizon des interactions avec le privé sur une note plus concrète pour la Région. Dans sa vision de la smart city, le CIRB a défini l’open data comme un des piliers de sa stratégie. Récemment, Agoria a clairement mis en avant le réel intérêt de l’Open Data comme moteur de développement économique (1.500 emplois et 180 millions d’euros). Bien que cela soit difficile à vérifier sur le terrain, les articles à ce sujet sont abondants. Nombreuses sont les villes qui ont déjà mis en place une politique d’ouverture des données. Des villes comme Rennes ou Gand listent d’ailleurs les applications qui ont été créées à partir de données ouvertes. Pour stimuler la création de ces applications, des hackathons sont également organisés.

Le CIRB a bien compris l’intérêt de l’Open Data puisque toutes les données UrbIS sont disponibles gratuitement et sans limitation depuis avril 2013. Mais notre ambition ne s’arrête pas là. Nous souhaitons amener d’autres institutions bruxelloises à partager également leurs données. Ce point est inscrit dans nos objectifs comme cela l’a encore été rappelé dans ce récent blogpost. L’idée derrière cet objectif est de laisser les entreprises, les communautés citoyennes, les développeurs, les startups décider eux-mêmes des services qu’ils peuvent créer à partir de ces données. Plusieurs projets sont en cours et nous ne manquerons pas de vous tenir au courant.

Garder les pieds sur terre

Mais cessons de rebondir et revenons les pieds sur terre ! La smart city est le buzzword du moment. Toutes les entreprises actives dans l’ICT en parlent. Toutes les villes veulent être smart et on ne compte plus les événements, congrès et autres workshops, organisés sur le sujet à travers le monde. La Région Bruxelloise n’échappe pas à la règle.

Au-delà de ce marketing, nous devons vraiment réfléchir à ce que nous voulons pour nos concitoyens et garder en mémoire les écueils de ce genre de concept tendance. Pour conclure, je vous conseille la lecture de cet article paru la semaine dernière sur le site de slate.fr à propos de Lyon, souvent citée comme exemple de ville smart. Bonne réflexion !

 

La ville trouve toujours son chemin

une clé USB dead drop (Aram Bartholl – Flickr)

Je suis un grand fan du professeur Ian Malcom. Mais si… souvenez-vous : ce matheux dégingandé de Jurassic Park, le 1er de la série (et le meilleur). En spécialiste de la théorie du chaos, il prophétise, dès le début du film, la catastrophe qui pend au nez de tous avec cette formule-clé : « Life always finds a way » (La vie trouve toujours son chemin). Dans la smart city aussi…

La vie. La ville. Le jeu de mots est facile, je le concède. Et pourtant : la ville et la vie sont indissociables et, dans la smart city aussi, la vie pourrait trouver son chemin. Au point de contrecarrer ou détourner les beaux plans imaginés par les spécialistes de la ville intelligente s’ils venaient à perdre de vue que les villes sont avant tout peuplées d’êtres humains. Et que ceux-ci sont d’indécrottables empêcheurs de tourner en rond.
Toutes les utopies sont vouées à l’échec. On peut donc le prédire sans grand risque à ceux qui voudraient penser la smart city comme un empilage de technologies. Mark Zuckerberg risque d’en faire les frais, lui qui a lancé l’idée de créer une Facebook City baptisée Zee-town. Cette ville privée, créée de toutes briques pour la coquette somme de 200 milliards de dollars à proximité du siège de Facebook dans les environs de San Francisco, accueillerait les 10.000 employés du premier réseau social mondial et leurs familles en leur offrant un cadre de vie premium, caractérisé par un haut niveau de services et de sécurité.

Il n'y a pas de ville “intelligente”

À des milliers de kilomètres de là, Masdar recherche habitants désespérément. Et pourtant, quelles ambitions ! « La Source » (masdar en arabe) devait devenir la première ville 5 zéros : zéro défaut, zéro carbone, zéro déchet, zéro pollution et zéro insécurité. Financée à coups de milliards de dollars par le gouvernement d’Abou Dhabi, Masdar se voulait un démonstrateur technologique à grande échelle pour quelque 50 000 habitants sur à peine plus de 5 kilomètres carrés. Mais, pour l’heure, malgré une vraie réussite en termes de climatisation naturelle en plein désert, la ville du futur ressemblerait plutôt à une ville fantôme, peuplée d’à peine 500 personnes
Quand bien même ces deux villes relèveraient le défi de se transformer en véritables ruches urbaines, seraient-elles pour autant d’authentiques cités ? Comme l’analyse Manuel Sanromá, le Monsieur Smart City de Barcelone jusque juin dernier, interviewé par le journaliste Francis Pisani, inlassable globe-trotter de l’innovation : « Il n'y a pas de ville “intelligente”. Ce sont les personnes et les communautés qui sont “intelligentes”. »
En d’autres termes, les villes ne seront intelligentes qu’à la condition de rester des villes (ou de le devenir). C’est-à-dire un agglomérat plus ou moins organisé d’hommes et de femmes dont la redoutable caractéristique est d’utiliser leur… intelligence pour modeler la ville à leur façon et, dans la smart city technologique, de détourner ou contourner les applis, réseaux, capteurs… La participation citoyenne est la pierre angulaire des smart cities. C’est sans doute la forme d’intelligence qu'il faudra s’employer à stimuler et que, du reste, les citoyens confrontés aux circonstances les plus extrêmes déveloperont le plus naturellement du monde. Le même Francis Pisani relate ainsi comment, à New York, les victimes de l’ouragan Sandy ont récolté des dons à l’aide… d’une liste de mariage d'Amazon !

Smart city orwellienne ?


Une clé USB dead drop (Aram Bartholl – Flickr)
 

Autre exemple ? L’idée d’une smart city orwellienne vous fait cauchemarder ? Afin de détourner de leurs activités, en l’occurrence de leurs échanges électroniques, les oreilles trop indiscrètes des Big Brothers en puissance, des petits malins ont imaginé le concept des « dead drops ». Rien à voir avec un quelconque jeu de la mort malsain : les dead drops ne sont rien d’autre que des clés USB. La particularité ? Elles sont scellées ici et là dans des murs d’enceinte ou d’immeubles et accessibles à tous afin de mailler « un réseau anonyme d’échange de fichiers hors ligne, de pair à pair et dans l’espace public ». L’idée a germé à New York (encore) dans le cerveau fertile d’un artiste berlinois en résidence dans la Big Apple en 2010 et, cocorico, dès la même année, Bruxelles avait sa première dead drop tout à côté de la place Flagey. Pas de doute, même dans les méandres high tech de la smart city, la ville retrouvera toujours son chemin !

Les mots pour le dire

discussion

Un article sur la communication… Un de plus certes, mais celui-ci pourrait vous amener à réfléchir d’avantage sur l’impact de votre message sur autrui. Ne dit-on pas que les mots peuvent être une arme ! Les régimes totalitaires de la planète le savent et ne se privent pas de pourchasser ceux ou celles qui maîtrisent le verbe. Pourquoi ? Eh bien parce qu’avec des mots, on peut faire s’écrouler des Etats mais aussi construire des ponts vers une nouvelle réalité. Avec des mots nous pouvons changer le monde. N’est-ce pas d’ailleurs le propre de la thérapie que de mettre des mots sur des émotions pour en prendre conscience et les apprivoiser ?
Dans les relations humaines, les mots ont une importance capitale. Le secret d’une bonne relation avec autrui se trouve souvent dans une communication honnête, sincère et dénuée de toute ambiguïté. Rien de nouveau, me direz-vous ! Et pourtant combien de fois omettons-nous d’appliquer ces principes avec nos proches, nos collègues, nos interlocuteurs en général.
Je vous propose d’aborder ici quelques principes à suivre et quelques écueils à éviter en communication afin de préserver une relation durable et constructive. Essentiellement  destinés aux relations manager-collaborateur, ces principes peuvent également être d’une aide précieuse pour les relations quotidiennes avec tout un chacun.

Le choix des mots

On se demande souvent quels mots employer pour exprimer une envie, une demande, une idée ? Le choix des mots est particulièrement important car il a un impact crucial sur le comportement d’autrui. C’est notamment à travers les mots que sera conditionné le résultat de vos demandes, idées, opinions auprès de votre interlocuteur. Les mots sont à la fois des moteurs et des freins à la motivation car ils peuvent être porteurs de charge émotionnelle. Les mots porteurs de charge positive favoriseront l’action, l’adhésion. Dans le cas contraire, ils entraineront au mieux une réaction de défense et au pire, le rejet pur et simple.
Ainsi, parler en termes d’échecs et de problèmes sera moins efficace que de parler en termes de résultats et d’objectifs.
De la même manière, ne dit-on pas souvent, en réaction à une demande qui nous semble difficile, voire insurmontable, « je vais essayer ». A cela, je rétorque toujours, « Avez-vous déjà essayé de vous assoir sur une chaise ? ». Non, bien sûr. On le fait, c’est tout. Pourquoi dès lors ne pas parler en termes de « faire » et voir alors les compétences, les moyens éventuels à mettre en œuvre pour y parvenir.
Cette approche de la communication a également pour avantage de placer son interlocuteur dans une dynamique de l’action, dans une énergie positive fondamentale pour la réussite de ce qu’il entreprend.   

L’usage inadéquat de la négation

Beaucoup d’expressions en entreprise, dans les médias, en politique (et ailleurs) font abondamment usage de la forme négative. N’entend-on pas régulièrement dire « Ne vous inquiétez pas », « Il n’y aura pas de réduction de coûts », « nous n’en ferons rien » et ce faisant, on risque de susciter chez autrui exactement le sentiment inverse à celui recherché. La formulation positive est plus salutaire : « Soyez rassurés », « Votre budget sera préservé », « nous poursuivrons dans cette voie ».
En outre, la négation est une figure de style que l’inconscient ignore lorsqu’il décode un message reçu. Si je vous demande « Ne pensez pas à un citron ! », quelle est l’image qui se forme dans votre esprit ? … Alors, convaincu ?
Sur le plan professionnel, si vous êtes manager et que vous gérez une équipe, il est important de veiller à formuler les objectifs de vos collaborateurs de manière positive. Si vous les formulez négativement, vous risquez de diminuer considérablement les chances de les voir se concrétiser. De la même manière, il ne suffit pas de demander à un collaborateur de ne plus faire quelque chose pour que le comportement cesse. Encore faut-il qu’il sache quoi faire en remplacement du comportement à éviter. A ce sujet, je vous renvoie à mon article « Figurant ou acteur de votre vie » dans lequel j’explique qu’il est important pour chacun de disposer d’un panel suffisamment large de comportements possibles face à une même situation. Si l’individu est restreint dans ses choix parce qu’il reste bloqué dans les ornières de ses modes de fonctionnement habituels, il ne pourra pas mettre en œuvre un autre comportement plus adapté.

Motiver plutôt que convaincre  

Si vous voulez maximiser les chances de voir se produire le changement escompté chez autrui, il est préférable de privilégier une approche qui se base sur le point de vue de la personne que vous cherchez à convaincre. Autrement dit, si vous argumentez sur base de votre vision des choses et que votre interlocuteur ne partage pas cette dernière, il y a fort à parier que cela génèrera davantage l’opposition que l’adhésion. Tout l’art de la négociation repose d’ailleurs sur ce postulat. En effet, pour obtenir l’adhésion, il est nécessaire de sortir de sa bulle et d’aller à la rencontre de l’autre pour utiliser ses propres arguments afin de lui montrer en quoi ce que nous demandons est en harmonie avec sa vision des choses. Celui qui manie aisément ce type de communication établira des relations solides avec autrui. Vos interlocuteurs se sentiront compris et respectés et seront bien plus enclins à vous suivre dans la direction donnée.
Aristote ne le disait pas autrement : « Si tu veux convaincre quelqu’un, utilise ses propres arguments. »
Il y a bien d’autres facteurs qui interviennent pour établir de bonnes relations avec autrui et maximiser votre influence. Ici, nous venons d’aborder le langage verbal. Le non verbal, quant à lui, (attitudes, mimiques, intonation, flux de paroles, etc.) est tout aussi important et ne doit nullement être négligé.
En conclusion, n’oubliez pas ce principe de base bien connu de la PNL (Programmation Neurolinguistique) : « Le sens de ma communication est dans la réponse que je reçois ».
Maintenant, à vous de mettre en œuvre ces quelques principes de communication. Ainsi, si aujourd’hui , demain ou la semaine prochaine la réponse de votre interlocuteur ne correspondait pas à l’objectif que vous cherchiez, posez-vous la question de savoir « qu’est-ce qui, dans ma communication, explique la réaction de mon interlocuteur ? ».

« Het probleem van België »

Brussel

Op de Franse nationale feestdag of all days publiceert de Financial Times een meer dan boeiend artikel dat in een handig tabelletje netjes een overzicht geeft van de belangrijkste Europese landen en het aandeel van hun hoofdtstad of hun « hoofdstedelijk gewest » in het Bruto Nationaal Product.

Het Bruto Nationaal Product per inwoner is een goed, alhoewel niet volledige, graadmeter voor welvaartcreatie.

Geen verrassingen: Londen is absoluut koploper. De regio Londen is rijker dan alle andere deelgebieden. London beheerst de Britse economie op een ongezien niveau in vergelijking tot andere grote Europese landen. Het is goed voor maar liefst 1/5de van het Britse Bruto Nationaal Product.

Ter vergelijking : Berlijn staat in voor een « schamele » 5% van het Duitse BNP. De Franse, Zweedse, Spaanse, Italiaanse en Nederlandse hoofdsteden scoren stuk voor stuk veel matiger dan het Verenigd Koninkrijk.

Iemand benieuwd naar de Brusselse score?

Onze hoofdstad, correctie ons Brussels Hoofdstedelijk Gewest, staat op de tweede plaats (Eerlijkheidshalve dienen wij hieraan toe te voegen dat Luxemburg niet is opgenomen in de recentste cijfers van Eurostat) en komt meteen na Londen in de rangschikking. Na Londen is het Brussels Hoofdstedelijk Gewest dus de tweede rijkste regio van Europa (Luxemburg even buiten beschouwing gelaten). U leest het goed, niet Vlaanderen maar Brussel is onze rijkste regio in Bruto Nationaal Product.

Opgelet: het BNP houdt geen rekening met wie woont in de regio, maar wie er werkt en produceert. Dus is het effect van de pendelaars niet te onderschatten in dit soort studie. Met andere woorden wie in Oost- of West-Vlaanderen woont, maar in Brussel werkt, telt dus mee voor de de Brusselse rijkdom. Op zich vrij logisch natuurlijk.

Het Centrum voor Informatica voor het Brusselse Gewest is m.a.w. actief « there where it happens » en dat maakt onze job elke dag meteen een flink stuk boeiender. De meeste van deze « verrijkende » projecten binnen het Gewest staan nu ook netjes opgelijst op www.smartcity.brussels. Uw smart Brussels project verdient hier zeker een plaatsje. Neem dus gerust contact met ons op mocht dat nog niet het geval zijn.

Want, rijkdom creëren is één ding, smart zijn is eigenlijk nog veel beter...

Zou onze blog in Vlaanderen trouwens even enthousiast worden gelezen als in het Brusselse?

Lectures de vacances

Lectures de vacances

Il est des lectures à priori fort peu informatiques et pourtant il est significatif de voir à quel point la technologie peut s’immiscer dans la littérature, à fortiori quand celle-ci s’intéresse à la vie de gens comme vous et moi dans la première moitié du 21ème siècle.

C’est la réflexion qui me vient à la lecture de la trilogie de Virginie Despentes, Vernon Subutex (dont deux volumes sont actuellement parus). Outre une foule de personnages aussi paumés qu’attachants et la description de Paris vécue au plus près, les réseaux sociaux sont presque un personnage en soi, car ils permettent de connecter de façon littérale des personnages au départ dispersés. Comme Despentes le déclare dans une interview « Dans le premier tome, Facebook était une véritable machine fictionnelle, comme un outil dont le personnage principal et l’auteur se servent, l’un pour trouver un toit le soir, l’autre comme ressort dramatique. Le deuxième tome est un roman en forme de sociographe : la visualisation d’un réseau social. »

L’auteur, à m'instar de tous ceux qui sont dans la cinquantaine (et je m’inclus donc dedans), appartient à cette génération qui a connu l’avant internet, et a une conscience très aiguë de ce que cela a bouleversé dans nos comportements de tous les jours. D'autre part, nous sommes encore assez jeunes pour ne pas être tout à fait perdus dans l’emploi de la technologie et chacun cherche à sa manière à se l'approprier, que ce soit via la réanimation du passé (« Dites, vous vous souvenez de ça ? »), le partage du présent ou le forum politique - je n’en veux pour preuve que les discussions enflammées en cours sur la situation en Grèce - le tout avec le recul sans doute dû à l'âge (enfin ça, ça reste à prouver...) .

De la dématérialisation vers la rematérialisation ?

Vernon Subutex peut se lire comme un roman sur les victimes (en l’occurrence un disquaire et des musiciens) de la dématérialisation des supports mais aussi une tentative de recouvrer justement un peu de cette matérialité dans les rapports humains et de ressouder d’abord virtuellement et ensuite concrètement un groupe d’amis que la vie avait séparé. Il y a d’ailleurs un côté délicieusement utopique dans Vernon Subutex… On pourrait y voir un salutaire rééquilibrage consécutif à un temps qui nous a vu nous ruer à corps perdu dans les mondes virtuels !

Mais foin de toutes ces considérations, Vernon Subutex est un sacré bon roman, d'une acuité impressionnante et Despentes, au delà des étiquettes marketing "punk, rock, trash et porno" s'avère une écrivaine (je dirais même plus, une auteure) remarquable.

Sur ce, bon été et bonnes lectures, quelles qu’elles soient !

Vernon Subutex, Virginie Despentes, tomes 1 et 2, éditions Grasset.

P.S. Ce n’est pas un hasard si je lis ce livre sur une liseuse électronique, ce qui permet d’emmener l’équivalent de plusieurs rayons de bibliothèques avec un poids et encombrement minimum....pensez-y avant de boucler vos valises ! 

Se préparer aux Containers et aux Microservices

rouages


Avec la mise sur pied d'un service d'intégration et déploiement continus, le CIRB s'est doté d'une équipe orientée DevOps, qui lui donne les moyens de poursuivre son évolution en matière de qualité des livrables et de mise à l'échelle de l'infrastructure. L'utilisation de containers et le développement de microservices en est la suite logique.
 
Fin des années 90, notre Data Center était composé d'autant de serveurs physiques que d'applications déployées. Début 2000, nous introduisions la virtualisation des serveurs. Dans un premier temps, nous considérions qu'une machine virtuelle s'utilisait à l'identique d'une machine physique. Sur chaque machine virtuelle, nous installions l'application et toutes ses dépendances. Progressivement, les serveurs physiques ont été reliés en cluster et nous sommes passés à l'ère du premier cloud. Les machines virtuelles pouvaient se déplacer "toutes seules" d'un serveur physique à l'autre en fonction de la charge. Nous avons pu isoler les serveurs virtuels dans des réseaux devenus eux-mêmes virtuels, de sorte qu'aux alentours de 2010, notre offre de services s'est étendue : IaaS, Paas, SaaS. Chaque serveur virtuel réembarque un système d'exploitation : Linux, Windows, AIX, … et sa licence. Notre paradigme était l'isolation de chaque application et ses dépendances dans un OS complet sur son serveur.
 
Depuis plus de 4 ans, nous nous sommes lancés, au CIRB, dans la voie de l'intégration et du déploiement continus. Nous avons pu le faire grâce à ces choix judicieux posés au fil du temps en matière d'infrastructure et d'organisation. Cette automatisation nous permet de redéployer le même serveur virtuel à répétition, mais aussi de répartir l'application et ses dépendances sur plusieurs serveurs.
 
Pour accélérer les déploiements, dans une approche DevOps, nous souhaitons nous assurer que le même produit composé d'un ensemble de services soit promu à l'identique et déployé de la même manière sur les différents environnements. Voilà pourquoi depuis près d'un an, nous utilisons des containers. Un container peut être construit en superposant instantanément, par construction, plusieurs couches logicielles, sans donc devoir passer par une phase de "setup, next, next,…". Il démarre très rapidement (une, deux secondes) et consomme peu de ressources car au lieu d’instancier un nouveau serveur virtuel, il utilise le système d'exploitation sous-jacent, tout en étant isolé et en pouvant communiquer dans un réseau privé avec d'autres containers. Cette technologie est disponible sous Linux. Microsoft annonce sa disponibilité dans sa prochaine release d'OS Server et l'a déjà intégrée à Visual Studio et Azure. Le format des containers devient interchangeable sous l'égide de l'Open Container Project, dans lequel vous retrouvez tous les grands acteurs y compris Vmware, Microsoft, RedHat ou The Linux Fundation.
 
Légers et performants, les containers peuvent être déployés, mis à jour en quelques secondes sur le poste du développeur, dans nos fermes vCloud voire chez d'autres providers : Azure, S3, OVH…. On parle vraiment de mise à l'échelle automatisée de l'infrastructure en fonction de la charge. Cela était impensable avec de simples machines virtuelles.
 
L'apport des containers pousse inévitablement à un autre regard sur le développement et la gestion des configurations.  En scindant l'application non pas en web-services mais en micro-services, encore plus petits, autonomes entre eux, ceux-ci peuvent être reconstruits, arrêtés, redéployés en autant d'exemplaires que nécessaire, automatiquement au fil de l'eau selon la charge, sans interruption de service. La mise en œuvre des micro-services, de leur développement à leur déploiement pour délivrer des services, demande de nouvelles approches de programmation et une plus grande maturité des outils de déploiements que les projets monolithiques. Pour préparer cette étape, le service d’intégration et déploiement continus, en relation avec les équipes projets et opérationnelles, concentre une partie de ses efforts sur l’orchestration.

Envie de rejoindre l’équipe ? Le CIRB recrute ;-)

La vélocité d’une équipe

entente de groupe

Ce blogpost s'inspire du modèle retravaillé de Mitch Lacey (Mars 2012), The Scrum Field Guide : Practical Advice for your First Year,  ainsi que d'Anis Berejeb (juin 2009), Le cauchemar de l’estimation (www.berejeb.com).

Introduction

Une équipe de développement logiciels peut s'apparenter à un moyen de transport : avant d’opter pour l’un ou l’autre choix, il est nécessaire d'évaluer leur efficience.  Pour les moyens de transport, cela concernera l'économie de carburant, l'importance des distances à parcourir, la fréquence d’utilisation voire le nombre de moyens de transport à emprunter par trajet, etc. Pour les équipes de développement logiciels, nous parlerons d’efficacité quant à la quantité de travail qu’elles peuvent terminer sur une période donnée et déterminée à l’avance.

Cette mesure est appelée vélocité (ou vitesse de développement, rapidité de développement, etc.) et son unité est généralement le point de récits utilisateurs (demandes utilisateurs).

Pour faire simple, la vélocité constitue le nombre moyen de points de récits utilisateurs qu’une équipe de développement peut réaliser sur une période de temps déterminée ("course de développement"), telle que définie par l’équipe de développement logiciels dans le critère "réalisé", aussi appelé critère "terminé" (K.Schwaber et J.Sutherland, Le guide SCRUM, Juillet 2013, p.16; C. Aubry, La vélocité n’est pas une mesure de productivité, Novembre 2007, www.aubryconseil.com).

Un moyen de transport n’en est cependant pas un autre, à l'instar d’une équipe de développement logiciels. Il y a une difficulté supplémentaire et non des moindres : une équipe de développement logiciels n'est pas "emballée" ou "étiquetée" avec une estimation de vélocité comme pourrait l’être une voiture pour sa consommation de carburant, par exemple.

La question qui se pose : comment prédire dans une certaine mesure la future vélocité d’une équipe de développement logiciels ?

Bien que nous pourrions utiliser la vélocité d’une autre équipe pour nous donner un point de départ pour notre future vitesse de développement, nous ne pouvons dire qu’une équipe dans l’entreprise est en quelque sorte plus efficiente, efficace ou rapide car elle a une vélocité plus élevée qu’une autre équipe : chaque équipe estime en effet différemment, selon ses propres bases de connaissance, critères et acquis, l’arriéré du produit.
On en arrive à une conclusion rapide (et un peu trop facile) : prédire la vélocité est une tâche difficile, surtout si l’équipe est nouvellement constituée et/ou béotienne dans le cadre du travail SCRUM.

Le modèle de travail

L’équipe de développement logiciels doit fournir au propriétaire du produit une estimation de ce qu’elle peut accomplir sur la course au développement. Une équipe de développement logiciels n’ayant pas encore participé à un calcul de vélocité ou n'ayant pas encore été actif dans le cadre de travail SCRUM se trouve rapidement confrontée à trois possibilités : l’utilisation de données historiques, l’estimation à l’aveugle et l’utilisation de données réelles.

Pour quelles raisons les équipes de développement logiciels ont-elles très souvent tendance à éviter ou à éliminer l'option des données historiques ainsi que celle de l’estimation à l’aveugle ?

Le souci des données historiques

Le rejet de l’option des données historiques est principalement du au fait que l’équipe n’a pas préalablement travaillé ensemble (et plus particulièrement dans un cadre de travail SCRUM). Il lui semble donc irréaliste et impossible de se baser sur l’historique d’une autre équipe de développement logiciels.

Toute équipe diffère logiquement d'une autre. La multitude des facteurs de différenciation est trop importante et ne peut générer un résultat réaliste: pensons notamment à la nouveauté de l’équipe de développement logiciels, à sa composition, à l’environnement politique, à la taille et à la complexité du projet, sans parler du propriétaire du produit et des clients associés :

  • La nouveauté de l’équipe de développement logiciels affectera sa vélocité dans sa réflexion.
  • Le calcul de vélocité dépendra de la qualité de composition de l'équipe.
  • Celle-ci pourrait encore être attachée à certaines approches dites traditionnelles (tel le modèle en cascade, le modèle en V, etc. - Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).
  • L’environnement politique peut aussi constituer une variable importante pour le calcul de la vélocité. Au fil du temps, les entreprises évoluent, modifient leur structure, leur stratégie et leur direction. Le plan annuel ou stratégique d’une société est peut-être devenu obsolète, les responsables clés peuvent avoir changé de rôles, changé la dynamique de l’environnement. Parfois ces changements sont évidents, parfois il sont beaucoup plus subtils. Tenir compte des données historiques doit permettre de prendre en compte toutes ces informations, ce qui peut être difficile à réaliser.  
  • Taille et complexité du projet sont tout autant à prendre en considération. Les équipes de développement logiciels, qu’elles soient nouvelles ou établies, qui s'occupent d'un projet qui a une technologie différente ou qui change de complexité ne peuvent s’appuyer sur ces données historiques.
  • Enfin, le dernier facteur concerne le propriétaire du produit et le client. Alors qu’en théorie ceux-ci ne devraient pas être considérés comme des variables, ils en sont et non des moindres. La vélocité en est donc affectée; la relation développée ou naissante devra s’approfondir tout comme les nouveaux membres de l’équipe devront développer au fil du temps cette approche (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.2).

L’utilisation de données historiques doit tenir compte au minimum des facteurs détaillés ci-dessus. Le calcul de la vélocité d’une équipe établie vous donne une idée de départ, mais utiliser ces données en tant que vélocité estimée et réelle pour sa propre équipe peut se révéler lourd de conséquences et demande prudence.

Ouvrir les yeux sur l’estimation à l’aveugle

Dans l’éventualité où il est impératif de fournir une estimation type avant tout autre travail d’ensemble, l’estimation à l’aveugle est une possibilité à ne pas négliger. Pour ce faire, il est nécessaire de réaliser un travail d’arrière-plan préalable avant « prédication » de la vélocité de l’équipe de développement logiciels.
Quelques étapes-clés d’une estimation à l’aveugle sont à respecter :

  • l’estimation de l’arriéré du produit  (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7),
  • la décomposition d'un récit utilisateur de référence,
  • la détermination d'une approximation de point de réalisation par heure,
  • l'identification d'une capacité de base de l’équipe de développement logiciels,
  • l'estimation d'une vélocité théorique de l’équipe de développement logiciels,
  • la communication de cette dernière comme un éventail de travail évolutif (entendons : non-fixe).

D’autres facteurs peuvent entrer en compte selon l’appréciation de l’équipe même. Déterminer ces quelques chiffres permet de faire une supposition, qui n’est qu’une idée. Certains spécialistes diront : « Débarrassez-vous-en, ils sont artificiels, il s'agit juste d'une béquille pour vous aider à démarrer ».

Estimer l’arriéré du produit

La première étape dans cette technique qui peut servir de base de calcul primaire de la vélocité de l’équipe est d’estimer l’arriéré du produit (que nous pourrions comparer à un carnet de commandes).
Dans l’arriéré du produit, avec l’équipe de développement logiciels, il est nécessaire d’identifier un récit utilisateur type, que l’équipe de développement logiciels estime à deux points de développement (pour rappel : c’est l’équipe de développement logiciels qui estime les récits utilisateurs, une bonne pratique d’estimation est d’utiliser la suite mathématique logique de Fibonacci).

Dès ce récit utilisateur trouvé et dès son estimation, il est nécessaire de passer tout l’arriéré des récits utilisateurs (Scrum Alliance Inc, SCRUM description, v1.1, 2012-2014, p.7).
La technique d’estimation préférentielle utilisée par l’équipe est la planification par poker. Toutefois, toute autre technique d’évaluation déjà connue peut être utilisée. Il est cependant important de ne pas mélanger les différentes méthodes d’estimation.

Décomposer le récit utilisateur de référence

Lorsque l’arriéré du produit est estimé en points, il convient de réaliser une liaison entre le temps exprimé en heure et le récit utilisateur.
Cette liaison sera la deuxième échelle permettant de visualiser à long terme une planification et d'établir un calcul de la vélocité.
Pour ce faire, il est nécessaire de prendre un récit utilisateur de référence à deux points (il peut être identique ou non au récit utilisateur précédent). Dans ce récit utilisateur, la découpe en tâches est nécessaire.

Lorsque l’équipe de développement logiciels a identifié les tâches pour la réalisation du récit utilisateur de référence, il faut estimer le nombre d’heures de ces tâches. A nouveau, la planification par poker permet de parvenir à des estimations réalistes. Une différence est notable : le travail s’effectue sur des heures et non sur un nombre de points.
De nombreux spécialistes de la méthode d’évaluation dans le cadre de travail SCRUM plaident pour une limite de maximum 13 heures par tâche (certains s’entendent qu’une tâche est égale à une journée de travail - Claude Aubry, Ne plus mesurer les tâches d’un sprint en heures, Février 2007, www.aubryconseil.com). Si ce n’est pas possible, cette tâche sera elle-même découpée afin de ne pas dépasser ce nombre (ou la journée de travail). A nouveau, la suite mathématique logique de Fibonacci est utilisée. Elle sera limitée à 13 (1,2,3,5,8,13).

Cette découpe est un peu plus complexe que la découpe en points car l’équipe estimera son propre travail et non pas une valeur métier sur un nombre de points. Dès lors, si un membre de l’équipe estime que la tâche peut se réaliser en 4 heures, il ne pourra pas choisir ce nombre d’heures mais devra prendre soit 3 ou 5 heures. Cette suite permet donc de maintenir un niveau de précision correct sans l’être trop.

Approximation horaire

Lorsque toutes les heures pour chaque tâche comprise dans le récit utilisateur de référence sont additionnées, nous pouvons alors extrapoler que tout récit utilisateur de 2 points vaut ce nombre d’heures. Prenons l’exemple que le récit utilisateur de référence vaut 15 heures : nous pouvons estimer que tous les récits utilisateurs précédemment jugés à 2 points devront être terminé en 15 heures. Cette estimation grossière est aux fins de l’estimation à l’aveugle.
Dès cette estimation réalisée, nous pouvons calculer une évaluation globale et non fixe de l’ensemble du projet en heures. Si le projet comporte 240 points dans son arriéré produit, nous pouvons estimer que le projet demandera environs 1800 heures de travail. A nouveau, s’il s’agit d’une nouvelle équipe dans un cadre de travail nouveau, ces données seraient trop incertaines. Le rapprochement de points vers le nombre d’heures permet de donner une estimation initiale. A nouveau, il ne peut être utilisé comme cadre de référence ou comme valeur précise (mais ce travail est utile, si si, je vous l’assure ! Nous le verrons par la suite…) !

La capacité de l’équipe

Pour déterminer la capacité de l’équipe, il est au préalable nécessaire de déterminer la période sur laquelle portera la course au développement. Cette période ne peut dépasser un mois (K Schwaber et J. Sutherland, Le guide SCRUM, Juillet 2013, p.9). L’échelle de temps de cette période est l’heure (Claude Aubry, Mon enquête sur les estimations, Novembre 2013, www.aubryconseil.com).
Chaque membre de l’équipe de développement de logiciels donne le nombre d’heures qu’il tient à disposition par semaine pour contribuer au projet. Ce nombre ne compte pas les activités qui interfèrent avec le temps de projet dédié. Cette estimation de contribution au projet est rentrée sous 2 formes : le meilleur des cas (le plus haut rendement) et le pire des cas (le plus bas rendement).
Les estimations les plus pessimistes sont additionnées. Ilf aut ensuite multiplier le nombre obtenu par le nombre de semaines de la course de développement. Faites à l’identique pour le meilleur des rendements. Ces deux nombres sont représentatifs quant à la capacité de l’équipe : celle-ci fournira au minimum autant d’heures et au maximum autant d'heures.

Estimer la vélocité de l’équipe

Lorsque tous les facteurs sont connus, estimer la vélocité de l’équipe n’est plus qu’une affaire de mathématiques. Il sera nécessaire de déterminer une vitesse de développement en éventail (à savoir une vélocité élevée et faible, afin de garder une période de développement et non une valeur précise).
Cette dernière se calculera avec le nombre d’heures de l’équipe de développement logiciels dans le pire des cas (plus bas rendement), divisée par la nombre de points par heure : le résultat sera la vélocité estimée à petite vitesse. Ce sera identique pour la vélocité à grande vitesse en remplaçant le premier nombre.
Nous pouvons maintenant communiquer que notre vitesse de développement est comprise entre telle et telle capacité ; l’arriéré du produit pourra être absorbé entre tel et tel mois.

L’utilisation des données réelles

L’équipe de développement logiciels peut prévoir sa future vitesse moyenne de développement. Pour certains, il y a un gros avantage dans cette méthode, à savoir l’utilisation de leurs propres données sur le projet en cours ; pour d’autres, il y a un gros désavantage : l’incertitude sur le laps de temps de la période de collecte de données. Refléter le fait et non la fiction l’emporte bien souvent sur l’inconvénient. Pour rassurer les responsables d’équipes de développement logiciels, il est toutefois utile de fournir une prédiction basée sur les méthodes précédemment citées en mettent en évidence le fait que seules les données réelles pourront donner une vélocité plus précise.

Pour réaliser l’estimation à l’aveugle, il est nécessaire de disposer de données réelles d’au moins 3 courses au développement. Cette collecte d’informations se réalise sur plusieurs points : collecter et calculer la vitesse de développement sur au moins trois courses au développement, calculer la vitesse moyenne et communiquer celle-ci comme nouvelle estimation, coordonner la capacité de l’équipe sur l’arriéré du produit.

Collecter les données réelles

La collecte de données de l’équipe de développement logiciels permet d’avoir une idée précise de la rapidité de développement fournie. Celle-ci est mensuellement affichée sous forme d'un graphique et discutée au sein de l’équipe de développement logiciels.
Calculer la vitesse moyenne de développement est maintenant réalisable. Toutefois il est nécessaire de ne pas la communiquer dans l’immédiat. Les raisons sont simples :

  • une nouvelle équipe
  • instabilité des données réelles sur un laps de temps plus pérenne
  • malentendus possibles sur des objectifs découlant d’un nombre prédéterminé

Lorsqu’on communique un délai fixe, on s’attend au fait que la tâche demandée dans le délai soit accomplie, sans report...

Prenons un exemple : notre bus doit passer à l’heure et non en avance ou en retard, sinon nous aurons la frustration soit de l’avoir raté, soit de devoir attendre un laps de temps plus long que ce qui est annoncé. A contrario, si j’indique un laps de temps (par exemple entre 5 et 10 minutes au maximum), la frustration ne sera pas présente - à condition que ce laps de temps soit effectivement respecté ! (Claude Aubry, Bacs, prévisions et incertitudes, Février 2015, www.aubryconseil.com )
La fourchette de temps permet donc de communiquer un délai raisonnable, si cette fourchette et l’échelle de temps le sont tout autant. L’idée est donc de sortir d’un laps de temps imposé pour passer dans l’éventail de planification : une proposition pessimiste, et une optimiste.

Pour en revenir à l’estimation à l’aveugle : dans un premier temps, ne communiquez pas cette échelle de grandeur hors de l’équipe de développement logiciels. Lorsque la collecte de données est terminée sur le laps de temps défini de 3 courses au développement, il est nécessaire d’additionner le nombre de points définis comme terminés sur chaque course au développement. Par la suite, divisez ce nombre par le nombre de courses de développement. Le nombre obtenu est le nombre moyen de points que vous pourrez sortir (la fourchette étant le nombre le plus petit et le plus grand). Si un trop grand écart est constaté, il est nécessaire de se rapprocher de la moyenne obtenue.

En conclusion

Il est nécessaire de prendre un laps de temps concret pour calculer la vitesse de développement d’une équipe. Privilégiez au maximum  une fourchette de développement, un éventail de temps, une période plutôt qu'une estimation proposant un nombre précis ou une décision précise (Claude Aubry, Vélocité, productivité et rock’n roll, Mai 2011, www.aubryconseil.com).

Les différentes méthodes de calcul présentées présentent chacune des avantages, des inconvénients et des spécificités. La plus préconisée est le calcul d’une vélocité sur des données réelles, mais c’est aussi celle qui demande le plus de temps pour gagner en certitude. Il faudra prévoir tout d'abord un calcul réalisé sur une estimation théorique puis une estimation sur des données réelles (David Baumier, Evaluer une équipe Agile, Janvier 2014, www.developpementagile.com).

Toutes ces méthodes de calcul de vitesse de développement font partie intégrante du cadre de travail SCRUM et facilitent la vie du responsable de produit, du responsable du cadre SCRUM au sein de l’équipe mais aussi celle des dirigeants pour la planification d’une livraison complète du produit. La souplesse de calcul et la fourchette gagnante permettront de modifier rapidement le planning si nécessaire...

Avenir numérique : demandez le(s) programme(s) !

Un labyrinthe

Alors que la saison invite plutôt à faire des plans pour les vacances, tous les niveaux de pouvoir convergent pour faire des plans sur l'avenir numérique de leur périmètre respectif.

Ainsi, la Commission européenne a dévoilé le 6 mai dernier son plan d'action pour construire un marché unique numérique (Digital Single Market), qui se décline en trois piliers et 16 actions :

  • 8 actions pour améliorer l’accès aux biens et services numériques dans toute l’Europe pour les consommateurs et les entreprises,
  • 5 actions pour une concurrence plus équitable
  • 3 actions pour numériser l'économie.

Quelques semaines plus tôt, Alexander De Croo annonçait le 20 avril 2015 son propre plan « Digital Belgium » qui se décline lui aussi en 5 piliers et 19 actions :

  • 6 actions pour renforcer l'économie digitale, et tout particulièrement rattraper le retard de la Belgique dans le domaine de l'e-commerce, notamment en assouplissant la réglementation en matière de travail de nuit,
  • 3 actions pour améliorer les infrastructures numériques,
  • 3 actions pour développer les compétences et l'emploi dans le domaine numérique,
  • 3 actions pour renforcer la confiance dans la sécurité numérique,
  • 4 actions pour stimuler les pouvoirs publics numériques.

Quant à la Région bruxelloise, comme annoncé dans l'accord de gouvernement, elle a lancé le 3 juin dernier, à l'initiative de Madame Bianca Debaets, secrétaire d'État de l'informatique régionale et communale et de la transition numérique, et avec l'aide du CIRB, sa grande convention du numérique, baptisée pour la circonstance Brussels Smart City Summit, qui se voulait une consultation de tous les stakeholders en préparation d'un plan d'action dans cinq domaines :

  1. Smart & Social
  2. Smart & Safe
  3. Smart & Services
  4. Smart & Infrastructure
  5. Smart & Mobile

Le CIRB avait lui-même déjà fait une série de propositions dans son Livre Blanc subdivisé en quatre défis (une région connectée, sécurisant, durable et ouverte) et sept chantiers.

Certaines communes bruxelloises s’y sont également mises : ainsi, la ville de Bruxelles vient de lancer son site Internet http://smartcity.bruxelles.be/fr et de gagner le Belfius Smart City Award pour sa plate-forme Open Data, avec l'ambition clairement affichée de jouer un rôle de pilote au sein d'une région-métropole.

Il faut aussi tenir compte des plans de simplification administrative au niveau fédéral et au niveau régional, qui doivent s'articuler avec tous les autres.

Et pendant ce temps-là, les pouvoirs publics tentent de tenir la tête hors de l'eau pour mettre en œuvre les plans antérieurs, entre autres pour transposer et mettre en œuvre :

(et j'en oublie certainement) et sans oublier la stratégie Europe 2020.
                                                                                                                                                                                                                                      
Bientôt, il nous faudra un plan pour nous y retrouver parmi tous ces plans !

Aïe - tech …

pré fleuri

Hum… ça vous fait sourire hein ? … Je suis presque certain que vous savez déjà où je veux en venir ! .. Aïe, la technologie, ce n’est pas facile au jour le jour, n’est ce pas? Le wifi, le bluetooth, l’usb 3.0, le web 2.0, iOS, Androïd…. C’est clair que ce n’est pas la simplicité dans son état le plus glorieux ! Mais bon… Que vous dire, sinon que ce n’est pas de ça dont je voudrais vous parler, mais du côté ‘aïe’ plutôt que du côté 'tech' ! …

La fée papillon

Que faites-vous lorsque Madame essaie une robe dans un magasin ? Assis, vous surfez sur votre smartphone ou debout, aux aguets, vous regardez cette belle dame qui se débat avec ses bretelles ? Et dans le métro ? Et dans le train ? Et dans le jardin ? Pourtant, à chaque fois, il y avait certainement une expérience intéressante à vivre… Mais, non, trop tard, c’est passé ! Le temps perdu ne se rattrape jamais… Papillonnons donc !

Tranche de mozzarella

Et si à la place de surfer dans le canapé, devant la télé qui fonctionne pour des prunes, vous alliez dans le jardin, avec une assiette de tomates-mozza préparée avec une bonne huile d’olives, quelques épices bien senties, un petit rosé bien frais et installé tranquillement sous le parasol ? (à condition que le soleil soit de la partie, nous sommes en Belgique tout de même !)

On est bien, non ? Tranquille… Sentez le vent amener les divines odeurs de votre assiette … Résistez un peu avant de dévorer, humez, regardez, appréciez…. Miam ! :oD

One week in your life

Maintenant que nous avons fini cette assiette, je vous propose de répéter l’expérience pendant une semaine. Non pas partir sur un régime tomates-mozza pendant 7 jours, mais plutôt … profiter d’une semaine de vacances pour … déconnecter vraiment !!!! Vous déconnecter des emails, des réseaux sociaux, du web, des appels et sms ‘pro’... Bref, dire au revoir au Aïe-tech pendant une semaine entière.

Gardez un gsm ‘toucon’ sur vous, car on ne sait jamais ce qu’il pourrait arriver… mais laissez le reste dans un tiroir :)

On en reparle ?

La réunion

plage de la Réunion

La Réunion est une île du sud-ouest de l'océan Indien. Heuuuu... non non non ! On verra cela une autre fois :)
La réunion est un rassemblement de personnes motivées par un sujet précis (par ex. le projet Intranet) et dont le but est de se mettre d’accord sur certains points, d’en faire avancer d’autres, de prendre des décisions.

Dans certains cas, il peut s’agir de réunions d’information, où une personne explique quelque chose pendant que les autres … écoutent attentivement !

On peut aussi pratiquer le brainstorming (dites bwèèènschto’minn’) où chacun balance tout ce qui lui passe par la tête sur un sujet tandis qu’une personne du groupe tente de prendre note entre deux fous rires.

Une réunion d’équipe peut aussi se mettre en place, très régulièrement de préférence, afin de passer en revue une série de points courts (suivant un ordre du jour) et d’y trouver des solutions/idées.

N’oublions pas la réunion ‘tasse de café dans mon bureau’ qui permet un échange rapide et désordonné d’informations entre deux cafés et une tranche de rigolade (soyons réalistes, m’enfin !)

Un dernier point : les réunions les plus courtes sont les moins longues ! … Long : c’est lassant, on perd vite le fil et notre concentration, les pv font des km ! A oublier ! Ou alors, c’est très structuré et ça reste plutôt dans l’idée d’une réunion d’information.

Enfin, sachez que la personne qui dirige la réunion l’anime aussi ! … Eh oui, il faut mettre du fun dans le Muppet Show :o)

Comment cela se passe ?

En général, très bien ! Il suffit d’être bien organisé ! Qu’est-ce que veut dire ‘être organisé’ dans le cadre d'une réunion ?
On ne peut pas faire plus simple, il faut :

  • un ordre du jour (ou OJ, les différents points à aborder)
  • le PV (le résumé de la réunion précédente)
  • une personne désignée pour la prise de note
  • du café, du thé (du temesta, c’est selon)
  • de la bonne humeur

Par contre, il est très important que l’OJ soit distribué bien avant la réunion (une semaine avant, c’est bien !), sinon il est impossible de préparer la réunion correctement. Pareil pour le PV, cela évitera de prendre 15min à le relire pendant la réunion.

Commencez par décontracter l’atmosphère! Tout le monde est ok avec le PV ? On y va les p'tis gars ? C’est parti !

Que fait-on?

Fondamentalement, après toute réunion on fait un PV qu’on envoie à tous dare-dare ! Dans le PV, on retrouve ce que chacun doit faire, ce qui a été décidé et l’état d’avancement des projets discutés.
Chacun a aussi ses notes, qui lui permettent d’avancer de suite à son retour au bureau.

Kit de survie (ou ‘que doit-on éviter ?’)

  • les réunions doivent être courtes
  • chacun doit savoir ce qu’il a à faire à la fin de la réunion
  • pas d’OJ -> pas de réunion !
  • préparez vos réunions, ne venez pas en touriste !
  • évitez les réunionnites :o)

 

Bon courage !

Alle blogposts