Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

I’m using Markdown as a markup syntax for many things: the syntax is indeed really simple to use, it lets me focus on the content I need to write, and it can later be converted to HTML for « real life » display once I’m done. In the open-source community, it has become largely spread, and many developpers use it, like me, for non code-related stuff, like keeping notes or writing their journal. Lire la suite »

La plupart du temps, pour tester si une clé est présente dans un tableau, il faut utiliser array_key_exists. Pourtant on trouve encore des empty et isset à sa place, en pensant que ces 3 fonctions sont interchangeables : ce n’est pas le cas. Fin 2016 on trouve encore des confusions, donc cet article me servira de référence pour les futures revues de code 🙂

Lire la suite »

C’est bientôt Noël. Et si vous vous faisiez le cadeau d’apprendre quelque chose de radicalement nouveau, comme un nouveau langage de programmation ?

Lire la suite »

La semaine dernière, j’ai eu un problème avec un exécutable, celui de wkhtmltopdf qui n’arrivait pas à générer de PDF et le log n’était pas clair. D’après certaines indications sur StackOverflow, ca pouvait être du à un problème de version de la librairie libjpeg. On peut le vérifier avec strace, c’est un utilitaire qui intercepte et loggue tous les appels systèmes, ce qui permet de voir ce qui se passe en fouillant dans les logs. Je ne connaissais pas cet outil, c’était une bonne occasion de découvrir.

La commande à inspecter est la suivante :

1
$ ./wkhtmltopdf-amd64 in.html out.pdf

On prend un fichier html en entrée, et on chercher à générer à en faire un fichier pdf.

Pour inspecter la trace d’exécution avec strace, on fait comme ça :

1
$ strace -f -o trace.log ./wkhtmltopdf-amd64 in.html out.pdf

L’option -f permet d’enregistrer égalements les appels systèmes des processus fils, -o indique un fichier dans lequel stocker les logs.

On peut ensuite chercher à voir quels sont les appels au chargement de libjpeg.so. On trouve vite ce qu’on cherche :

1
2
$ cat trace.log |grep libjpeg
18590 open("/usr/lib/x86_64-linux-gnu/libjpeg.so.8", O_RDONLY|O_CLOEXEC) = 3

On voit donc que l’exécutable cherche à charger libjpeg dans sa version 8 dans un répertoire particulier. En cherchant les installations de libjpeg ($ locate libjpeg), j’ai pu voir que la version installée sur la machine en question est libjpeg.so.62, ce n’est donc pas la bonne version, un problème résolu avec un

1
apt-get install libjpeg8

. Bref, un problème pas banal mais qui m’a permis d’apprendre plein de choses 🙂

J’ai eu l’occasion de participer à plusieurs projets, le plus souvent de développement. Ils ont eu des durées et des importances variées. Certains se sont cassés la figure d’une manière ou d’une autre, et d’autres se sont très bien passés. Ces expériences m’ont permis de constater quelques unes des caractéristiques de projets qui marchent bien. Cela n’est pas valable que pour du développement, cela marche pour vraiment n’importe quel type de projet.

Quand je parle de réussir, je ne m’intéresse ici qu’à la réalisation technique du projet. C’est mon métier. Ce n’est pas le seul, et souvent d’autre éléments sont en jeu, l’aspect commercial par exemple. en sont un autre et je ne suis pas la bonne personne pour en parler.

Deux manières de procéder

Il y a plusieurs manières de lire cette liste :
  • Lancement d’un projet : elle peut servir de checklist
  • Projet en cours : risquez-vous d’aller dans le mur ? Vous pourrez peut-être corriger le tir.
  • Projet terminé : permet d’en faire une rétrospective, où l’on peut identifier quels éléments du projet étaient fragiles

Caractéristiques clé

Facile à comprendre

Les projets sont souvent rangés dans une application de gestion de projet (cela peut être un simple fichier google doc partagé, ou bien dans Jira, Trello…).

Le titre du projet, ou bien la définition macro du besoin doivent être clairs. Au premier contact avec un projet, ce qui se fait souvent par un titre assez succin, on doit savoir de quoi il retourne.
Si ce n’est pas le cas, c’est en général mauvais signe : « Ce qui se conçoit bien s’énonce clairement ». Si l’initiateur du projet ne fait pas l’effort de présenter son projet clairement ou si le projet est flou car le projet lui même n’est pas encore abouti, il risque d’y avoir des problèmes de communication rapidement.

Le périmètre fonctionnel est clair

Il ne doit pas y avoir d’ambiguïté sur ce qui doit être réalisé. Cela peut être lié au problème précédent (préférer « Concevoir l’interface de gestion des messages privés entre utilisateurs » à « Outils de discussions interne »).

Lorsque le titre ne suffit pas à préciser ce qui doit être fait, il faut aller plus loin : texte de description, maquettes, documents de spécification… Tout dépend du projet et de l’autonomie dont dispose (en théorie, et surtout en réalité) l’équipe.

Les actions à réaliser sont listées de manière exhaustives et précise

Avant de commencer à faire quoi que ce soit, on doit savoir ce qu’il faut faire; c’est un travail collaboratif ! Seul, on a vite fait d’oublier une tâche qui va s’avérer importante par la suite, en minorer le temps nécessaire ou l’importance. Tous les acteurs du projet doivent contribuer à lister ce qui doit être fait, et réfléchir à leur faisabilité.

Certaines actions ne seront pas forcément réalisables immédiatement (ex: la migration d’un module dans un nouveau framework nécessite la refonte du modèle de base de données). Il faut trouver des solutions (ex: bridge temporaire avec l’ancien modèle, et initiation d’un projet plus globale de refonte du modèle).

Cette étape est cruciale car on a vite fait d’omettre des éléments clés qui peuvent remettre en cause le temps effectif de réalisation, ainsi que les choix techniques mis en places.

Les livrables sont définis précisément

Livrer un site responsive, ce n’est pas la même chose que livrer un site ET une application mobile. Cela peut sembler évident, mais ca ne l’est pas. Penser à lever les ambiguïtés et les non-dits sur ce qu’il faut rendre en fin de projet.

Les experts et les ressources matérielles sont accessibles

Dans n’importe quel projet on a besoin d’avoir accès à des personnes et des ressources. Les personnes vont par exemple avoir une expertise métier nécessaire à la conception du produit (ou plutôt à l’avant projet, ce qui peut être considéré comme un projet en soit).

Les ressources matérielles nécessaires doivent également être fournies ou disponibles. Cela peut être :

  • Les accès aux différents serveurs nécessaires (base de donnée, accès SSH)
  • Les licences nécessaires (IDE, applicatifs, outils SaaS…)
  • Les applicatifs sont correctement configurés. Si ce n’est pas le cas, on doit avoir la possibilité de le faire. Le temps nécessaire devra alors être anticipé et alloué pour cela

Quoi qu’il en soit, il faut savoir à l’avance de quoi on aurait besoin et pouvoir y avoir accès lorsque c’est nécessaire.

Une date butoire réaliste

Ha, les estimations… On ne va pas se mentir, les estimations, c’est de la magie noire et personne ne peut prédire précisément le temps que va prendre la réalisation d’un projet.

C’est pourtant un indicateur clé qu’il ne faut pas négliger. Elle doit être réaliste : si on laisse 15 jours pour faire quelque chose qui prend de toute évidence 2 mois, on va dans le mur en niant l’évidence (c’est plus courant qu’on ne le croit).
La pertinence d’une date butoire est difficile à évaluer a priori, mais on peut mesurer sa dérive en cours de projet. A mi-projet, on peut tenter d’estimer si on est encore dans les clous ou si on est déjà foutus. Si on a de l’avance (c’est plus rare que l’inverse), en profiter pour améliorer la qualité.

Découper en milestones

Si le projet est long, il peut devenir pertinent de le découper à l’aide de milestones, des dates clés auxquelles on va vérifier un certain nombre de choses (livrables intermédiaires). On peut alors considérer chaque milestone comme un sous projet, qui doit alors avoir les mêmes caractéristiques que le reste (date butoire réaliste, livrables précisément définis, etc.)

Pas d’interruptions

Nous, les humains, sommes très mauvais pour faire deux choses à la fois. Quand on travaille sur un projet, c’est mieux de se concentrer sur celui ci plutôt que d’essayer d’en développer plusieurs à la fois. Passer d’une tâche à l’autre est une catastrophe pour la concentration. Quand on est sur un projet, cela veut dire, autant que possible : pas de debug d’un autre projet, pas de R&D en parallèle du projet…

Cela n’empêche pas de le faire, et c’est d’ailleurs ce qui arrive assez souvent. Dans ce cas, le temps nécessaire à la réalisation des diverses tâches et projets doit être clairement défini et alloué dans ce sens.

Eviter de changement

Les caractéristiques décrites ici s’insèrent très bien dans une méthodologie agile, qui prône une réactivité presque totale au changement. D’une itération à l’autre, ce qui est conçu peut être jeté pour faire complètement autre chose que ce qui était prévu au départ. C’est une bonne chose (pas forcément toujours bonne à entendre pour le développeur qui conçoit l’application, certes), car elle permet d’assurer que le produit réalisé est bien le bon.

Par contre, il faut un peu de rigueur pour utiliser cette méthodologie correctement, et ne pas interrompre ou altérer un sprint à tout bout de champ. Ajouter de nouvelles tâches, ou modifier les tâches existantes est le meilleur moyen d’aller dans le mur en croyant bien faire. Rapidement, cela peut réduire à néant tout ce qui a été précieusement préparé (périmètre fonctionnel, livrables attendus, date butoire qui devient difficile à respecter, etc.), tout en faisant baisser la qualité du résultat ainsi que la motivation des parties prenantes.

Tout est communication

Finalement, toutes ces remarques gravitent autour de la problématique de la communication. N’importe qui devrait pouvoir comprendre les caractéristiques du projet, et en comprendre les tenants et aboutissants. Il ne doit pas y avoir de non-dits, ou d’idées tacites qui ne soient pas exprimées, explicitées, clarifiées, couchées sur papier.

Ce qui est clair pour quelqu’un ne l’est souvent pour plusieurs personnes que quand elles en ont discuté et se sont mises d’accord à grand coup de schéma. Noter le résultat permet d’y revenir plus tard.

Vous constaterez probablement qu’il n’y a rien de fou dans cette liste et probablement pas d’idée nouvelle. Comme souvent en management ou en gestion de projet, il est question de bon sens. Bien que tout le monde croit en avoir, trop souvent les les projets en manquent d’une manière ou d’une autre. La clé d’un projet qui démarre bien, c’est finalement la rigueur avec laquelle il est décrit.

Gérer les cases à cocher avec angularJS est un peu plus compliqué que les autres associations. On ne peut pas simplement utiliser ng-model, il faut gérer la possibilité que plusieurs cases soient cochées et cela nécessite d’implémenter cette logique métier.

Nous allons voir comment le faire à la main, puis à l’aide de la directive checklist-model.

Gérer la checkbox « à la main »

Le moyen le plus simple, c’est d’avoir un tableau des différentes possibilités, de boucler dessus. Pour chaque case à cocher, lors d’un clic on va déclencher une action de contrôleur. On va également tester si la case est cochée ou non via une autre action de contrôleur.

1
2
3
4
5
6
7
8
9
10
11
<ul class="checkboxes">
    <li ng-repeat="(key, text) in availableTypes">
        <label>
            <input type="checkbox"
               name="filterType"
               ng-click="toggleTypeSelection({{ key }})"
               ng-checked="isTypeChecked({{ key }})">
                {{ text }}
        </label>
    </li>
</ul>

Il faut donc dans le contrôleur plusieurs choses :

  • Une liste des différentes possibilités (availableTypes)
  • La propriété qui va stocker le modèle (types)
  • Une méthode pour dire si une case est cochée ou non (isTypeChecked)
  • Une méthode pour cocher les cases (toggleTypeSelection)

Le javascript associé contient donc ces quatres choses :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$scope.types = [];

$scope.availableTypes = {
    'apple': 'Pomme',
    'peach': 'Peche',
    'pear':  'Poire'
}

// Dit si une case est cochée
// en testant si le tableau types contient la propriété testée.
$scope.isTypeChecked = function(typeName){
    return $scope.types.indexOf(typeName) > -1;
}

// Coche ou décoche une case
// en ajoutant ou supprimant une propriété du tableau types
$scope.toggleTypeSelection = function(typeName){
    if ($scope.isTypeChecked(typeName)) {
        var index = $scope.types.indexOf(typeName);
        $scope.types.splice(index, 1);
    }
    else {
      $scope.types.push(typeName);
    }
}

Factorisation grâce à checklist-model

En fait, on se rend assez vite compte que les deux actions de contrôleur sont toujours les mêmes. Pour éviter de devoir la réécrire à chaque fois, on peut donc les factoriser, dans une directive ou un service. Plutôt que de le faire soi-même, il existe une directive, checklist-model qui fait cela.

Le code HTML fait la même taille, mais la philosophie est différente. checklist-model devient l’équivalent du classique ng-model, et checklist-value va devenir la propriété à ajouter au tableau types lorsque la case est cochée ou non. La directive peut également savoir si une case est cochée, en testant si le tableau du modèle contient cette propriété.

1
2
3
4
5
6
7
8
9
10
<ul class="checkboxes">
    <li ng-repeat="(key, text) in availableTypes">
        <label>
            <input type="checkbox"
               checklist-model="types"
               checklist-value="key">
                {{ text }}
        </label>
    </li>
</ul>

Le contrôleurs devient beaucoup plus simple. Il n’y a plus besoin d’implémenter les logique d’actions au clic, et pour tester si une case est cochée, c’est géré par la directive. Il suffit de déclarer les différents tableaux :

1
2
3
4
5
6
7
$scope.types = [];

$scope.availableTypes = {
    'apple': 'Pomme',
    'peach': 'Peche',
    'pear':  'Poire'
}

Il est facile d’ajouter des fichiers invalides dans un système de contrôle de version si on ne fait pas attention. Un des moyens d’éviter ça, c’est d’utiliser les hooks de git.

On peut « s’accrocher » à un événement, et exécuter du code à ce moment. Git permet de le faire à peu près n’importe quand : avant un commit, avant un push, après un checkout… La liste complète des possibilités est dans la doc.
Pour cela, il suffit d’ajouter un script shell dans le répertoire .git/hooks d’un dépôt git. On peut d’ailleurs y trouver quelques exemples (inactifs, il faut les renommer pour les « activer »).

Pour éviter de soumettre des fichiers à la syntaxe invalide, on peut donc écrire un hook pre-commit en creant le fichier pre-commit dans ce répertoire. Ce script s’exécutera avant que le commit soit réalisé lorsque l’on exécute la commande commit.

Voici son code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/sh
# On récupère la liste des fichiers modifiés
modifiedFiles=`git diff --cached --name-only --diff-filter=ACM`;
error=false;

for file in $modifiedFiles; do
# On vérifie la syntaxe des fichiers PHP avec php -l
   if [[ $file =~ .*\.php ]]; then
      result=`php -l $file 2>&1`;
      if [[ $result =~ .*'Parse error'.* ]];
      then
         echo $file;
         echo $result;
         error=true;
      fi;
   fi;
done

if [ $error != false ]; then
   # En cas d'erreur on empêche le commit
   echo "Erreur de syntaxe dans l'un des fichiers";
   exit 1;
fi;

Le code est simple et commenté, le comprendre ne devrait pas poser de problème (l’écrire a demandé quelques coups de main à google ceci-dit. bash, quelle galère…). La vérification de syntaxe se fait avec php -l, le linter de PHP, en parsant le texte de sortie car il n’y a pas de code de retour qui permette de déduire une erreur de syntaxe. En cas d’erreur, on interrompt le commit et on affiche les fichiers à corriger. Simple et efficace.

On pourrait bien sûr faire d’autre vérifications : validation de la syntaxe des fichiers JavaScript avec jslint, assurer le bon respect des règles de codage avec PHPCS

Plus d’informations sur les hooks dans la documentation.

Un des problèmes majeurs de l’entreprise, c’est l’engagement de ses employés. Souvent, dans une entreprise, les gens sont motivés lorsqu’ils prennent un poste, mais rapidement de nombreuses contraintes et barrières les empêchent de mettre en oeuvre les bonnes idées qu’ils peuvent avoir. Rapidement, ils finissent alors par faire comme tout le monde, « faire leurs heures » et attendre de rentrer chez eux pour commencer leur vie.

Une entreprise libérée cherche à résoudre ce problème (et de nombreux autres, comme nous le verrons). C’est une entreprise dans laquelle les employés mettent en place tout ce qu’ils trouvent favorable au développement de l’entreprise, sans procédures asphyxiantes.

Entreprise libérée

L’introduction a présenté quelque chose d’assez flou, voici quelques précisions. Le reste de l’article a pour but de préciser les motivations et l’état d’esprit d’une entreprise de ce genre.

Une entreprise libérée, c’est une entreprise qui a un certain nombre de croyances.

  • Elle pense que l’Homme est naturellement bon, que les gens sont des gens biens, qu’ils ont envie de bien faire et qu’ils font de leur mieux
  • Elle est convaincue que l’intelligence collective, c’est quelque chose de très fort
  • Elle sait que le patron de l’entreprise est la première personne qui doit changer pour que l’aventure fonctionne

Chronoflex ?

Début janvier, nous avons rencontré Alexandre, dirigeant de Chronoflex. Ils font du dépannage sur site de flexibles hydrauliques, 24h/24, 7j/7. Ca a pas l’air super sexy et pourtant, ce qu’il nous a présenté est à des années lumières de ce que l’on aurait pu imaginer d’une entreprise de ce genre. Il a parlé de son entreprise, sans langue de bois, en nous présentant ce qui marchait et ce qui ne marchait pas.

Créée en 1995, la vision initiale de l’entreprise fonctionne de 1995 à 2009. Pendant cette période, l’entreprise est en forte croissance (parfois, à 3 chiffres). C’est une boite jeune, où il fait bon vivre et où on s’amuse bien. En grossissant, elle finit par se structurer, comme partout ailleurs.
La croissance se fait pendant 10 ans. Avant, pas de recherche de rentabilité. Elle arrive à faire 22 millions d’euros de chiffre d’affaire, avec 250 personnes.

En 2009, la crise les frappe de plein fouet. Ils font -34% de chiffre d’affaire. Cette entreprise qui gère bien une période de forte croissance n’est pas faite pour encaisser une période de décroissance.

Deux rencontres, à quelques années d’intervalle, vont amener l’entreprise à se redresser.
La première, c’est de rencontrer le dirigeant de l’entreprise Favi, lors d’une conférence. Jean François Zobrist fait depuis des années des conférences où il incite les entreprises à dé-hiérarchiser, et à supprimer le contrôle et le remplacer par la confiance. C’est un personnage à la forte personnalité qui va lui faire prendre conscience qu’il faut changer des choses dans son fonctionnement.

Alexandre constate qu’il a fait deux erreurs :

  • La première, c’est de gérer l’entreprise pour les 3%. Mettre en place plein de règles qui gênent la majorité des gens, à cause d’une minorité, les 3%. Ces murs invisibles empêchent les 97% de gens qui cherchent à faire de bonnes choses.
  • La seconde, c’est d’avoir confié la prise de décision à des dirigeants. Les gens les plus compétents pour savoir ce qui est bon de faire sont souvent ceux qui font le travail, et se priver du savoir collectif c’est souvent se priver de la première richesse de l’entreprise : ses employés.

3 chantiers

Pour changer, ils ont silloné la France, armés de Post-it. Partout, ils ont discuté, échangé avec les différentes structures afin de reconstruire la vision de l’entreprise et les valeurs qu’elle porte. Il s’agit de définir, d’expliciter deux choses :

  • Quel est le but du jeu ? C’est à dire, à quoi sert l’entreprise ?
  • Quelles en sont les règles ? C’est à dire, comment on fait ça ?

Les visions et valeurs

Une des premières questions pour laquelle ils ont cherché à trouver une réponse, c’est de définir, d’expliciter la vision et les valeurs de l’entreprise.
Ils ont trouvé quatre éléments de réponses :

  • Atteindre la performance par le bonheur
  • L’amour du client
  • Des équipes respectueuses et responsables
  • Un esprit d’ouverture et une ouverture d’esprit

Les irritants

Vous avez déjà essayé de marcher avec un caillou dans la chaussure ? On peut s’y habituer, mais c’est super pénible.
C’est pourtant ce qui arrive rapidement. Un ordinateur qui ne marche pas, du manque de matériel, des incidents récurrents, des procédures compliquées…

Un grand nombre de détails sont finalement des problèmes irritants qui deviennent parfois obsédants. En enlevant les cailloux, l’entreprise a permis à ses employés de se concentrer sur leur travail.

On a par exemple permit aux employés de faire du télétravail. Les études sur le sujet constatent qu’un employé en télétravail travaille 13% de moins en durée, mais est 22% plus productif. Il faut de tout pour arriver à un équilibre, mais permettre le télétravail lorsque l’employé le souhaite (pour ne pas poser une après midi pour en rendez-vous médical) ne doit pas être négligé.

Attention, n’abandonnez pas le travail sur site, en groupe. Il permet, lui, de stimuler les idées et la motivation. Si l’on prend l’exemple de qui veut gagner des millions, une étude a montré que l’appel à un ami gagne dans 64% des cas, alors que l’avis du public est bon dans 80% des cas. Ensemble, on ne gagne pas tout le temps, mais on gagne plus souvent que seul.
Il y a ainsi plus d’efficacités dans le collectif que dans quelques esprits aiguisés, ce qui peut être résumé par cette phrase : « Seul, on va plus vite, ensemble, on va plus loin ».

Les signes du pouvoir

Sans forcément faire attention, un certain nombre de choses étaient devenus des signes de pouvoir :

  • Les dirigeants ont des grands bureaux, plus grands que les autres
  • Le patron, bien qu’il n’avait pas de place attitré, avait toujours la place la plus proche de l’entrée. Au départ, c’est parce qu’il arrive plus tot que tout le monde, mais quand il part en visites, « sa » place est toujours libre
  • Les réunions secrètes du Codir. Il ne s’y passe rien de secret, et pourtant cela se passe en huis clos, sans que personne ne sache jamais se qui s’y dit.
  • Internet était bloqué pour les employés, afin qu’ils n’aillent pas sur Internet pour leur usage personnel. La solution mise en place bloquait tellement de choses qu’il était impossible de réserver un billet de train. On a donc désactivé ce bloquage pour les dirigeants.
  • Les postes à responsabilité : Directeur marketing, Directeur financier, etc.

Afin d’arrêter de donner l’image selon laquelle les dirigeants détiennent plus la vérité que quelqu’un d’autre, ils ont changé un certain nombre de choses. Par exemple, les réunions du Codir sont devenues ouvertes à tous, ceux qui étaient dans les locaux pouvaient y venir. C’était déjà le cas avant, en fait : mais comme personne n’avait expliqué qu’on pouvait y venir, les gens étaient persuadés que c’était une réunion fermée. Le dirigeant a également arrêté de mettre un costume, et a arrêté de se garer devant l’entrée, pour montrer que la place qu’il occupait le plus souvent ne lui est pas attitrée.

En ce qui concerne à Internet, oles bloquages ont été supprimés. Oui les gens utilisent Internet pour leur usage personnel, mais le principe d’avoir confiance en ses employés, c’est d’accepter l’idée qu’ils soient capables d’en faire une utilisation raisonnée.

Quand aux postes à responsabilité, comme directeur marketing, ces postes ont deux composantes, une expertise opérationnelle et une composante décisionnaire. Ils ont supprimé le titre, gardé l’expertise opérationnelle et donné aux équipes la prise de décision (cela n’a pas toujours été bien vécu mais de l’accompagnement au changement a été proposé).

Liberté & compagnie

La seconde rencontre clé, c’est la lecture du livre Liberté et Cie. Cette étude analyse le fonctionnement classique des entreprises, et étudie surtout des entreprises qui ont choisi des fonctionnements alternatifs.

Ce livre propose une sorte de recette pour libérer l’entreprise :

  • Ecouter ses collaborateurs. Cela commence par arrêter de parler, soi, et d’écouter, sans filtrer, ni influencer.
  • Partager sa vision. La vision est essentielle à l’entreprise, il faut la répéter. Mais il faut le faire après avoir vraiment écouté les collaborateurs.
  • Arrêter d’essayer de motiver les collaborateurs. Le management par l’incentive, avec des primes, des salaires variables sur objectifs individuels… plus globalement, le système du baton et de la carotte ne marche pas. Ca ne motive pas les gens, ça ne sert à rien, du moins pas suffisament. Le livre suggère donc de trouver d’autres moyens d’être performants : L’homme est programmé pour 2 choses, le plaisir et la maîtrise. Pour que le collaborateur soit performant, l’entreprise doit lui construire un environnement dans lequel son travail n’en semble pas, et où il a le contrôle de ce qu’il se passe.
  • Le triptyque de l’engagement :
    1. Supprimer les signes de pouvoir
    2. Créer un environnement nourricier, qui va permettre aux gens de monter en compétences
    3. Laisser place à l’action en donnant de l’espace aux employés pour qu’il puisse faire ce qu’ils considèrent être bon pour l’entreprise.

Le but, c’est d’atteindre un vrai management participatif. Souvent, le management participatif classique consiste à demander aux gens leur avis, mais en ayant déjà plus ou moins le sien à l’avance, et ne pas modifier ses idées en fonction de celles des autres.

Le vrai management participatif se fait en deux temps :

  • Partager tout ce que les dirigeants connaissent sur un sujet, fournir tous les éléments de réflexion qu’on possède aux employés
  • les laisser décider

Une étape essentielle, c’est le coaching, l’accompagnement.
La première personne qui doit changer sa vision, c’est le dirigeant. Elle doit se faire coacher.
Ensuite, les équipes, si elles souhaitent se remettre en question, doivent pouvoir se faire accompagner.

Le saut en parachute

Les premières étapes de ce chantier ont eu lieu de manière sous marine. Il n’y avait pas encore de communication globale sur ce changement, pour pouvoir revenir en arrière si cela n’était pas une bonne solution.

Pendant 18 mois, des actions ont eu lieu mais il n’y a pas eu d’annonce. Les dirigeants et des équipes ont travailllé avec un coach pour désapprendre les croyances et travailler sur lui/elle. Beaucoup de lectures / coachs (Favi et Liberté & Cie).

Le saut en parachute, c’est le moment où il y a cette communication globale, après que l’on ai décidé que c’est la voie à suivre.
Saut en parachute, car comme ce sport, c’est un acte irréversible. Une fois qu’on a sauté, il n’est plus question de remonter dans l’avion.

Ils ont donc fait une réunion clé, où a participé toute l’entreprise. Ils ont décidé, en quelques heures, de transformer ce qui était devenu un porte avion lourd a manoeuvrer, en plusieurs speed boat, plus rapides et maniables.

  • Où ? Les employés ont décidé de l’emplacement des 13 succursales
  • Qui dirige ? Les employés, à nouveau, ont coopté leurs leaders, les dirigeants de ces succursales, pour des mandats de trois ans.

C’était super : en l’espace d’1h30 ils avaient redéfini l’entreprise. Humainement, quelque chose de fort était en train de se passer.

Pourtant, ils se sont cassés la figure assez rapidement.

Ils ont mis en place seulement deux points du triptyque de l’engagement (supprimer les signes de pouvoir et donner les moyens aux employés), mais il en manquait un. Sans avoir créé d’environnement nourricier, sans avoir formé les gens, ils n’ont pas réussi leurs premières missions. Ils ne sont pas à blâmer, ils n’étaient pas équipés pour.

Au moment de la libération, on passe d’un structure où aucune information n’est accessible à une structure où tout est accessible. C’est difficile à gérer pour beaucoup, il faut de l’accompagnement et du coaching.

Finalement, ce changement est un changement de différents types de logiques.

  • Au lieu de dire aux gens ce qu’ils doivent faire, on passe à une logique de volontariat.
  • Au lieu d’être dans une logique de contrôle, on est dans une logique d’autocontrôle. Il y a une différence, que ce soit dans les faits ou dans la perception, entre le flicage et l’auto évaluation.
  • Rentrer dans une logique de culture de l’erreur.

En poussant un peu plus, au moment du saut en parachute ils ont constaté 4 types de comportements :

  • les papillons : certains des employés ont tout de suite été à l’aise
  • les paumés : la plupart des gens. Ils ne savent pas ce qu’ils peuvent faire et ne pas faire
  • les attentistes : ceux qui attendent de voir qui va gagner, l’ancien système ou le nouveau ? Ils prendront position en fonction du résultat.
  • Les chefaillons : des personnes qui ont besoin de pouvoir, et qui ne se retrouvent pas dans la nouvelle organisation

Accepter de mettre en place une culture de l’erreur

Ils se sont plantés ? Tant pis.

En France, on aime pas l’erreur. C’est très culturel. On peut prendre l’exemple des dictées à l’école, où chaque mot érronnée est entouré d’un rouge accusateur. On ne parle pas de tous les autres mots qui sont justes. On ne voit que l’erreur, et il ne faut pas se tromper, c’est mal.
On pénalise donc l’erreur au lieu de la valoriser.

Pourtant, ne pas avoir peur de l’erreur est essentiel dans une entreprise.

Quand on se plante, c’est qu’on a osé. Si on tape sur les doigts de quelqu’un qui se plante, il se plantera une fois ou deux mais pas 50. C’est un problème ! L’employé va finir par ne plus oser. Et si on n’ose pas, l’entreprise ne se développera pas.

le travail du dirigeant

  • Communiquer sur les valeurs de l’entreprise au quotidien, « remettre l’église au centre du village »
  • Créer un environnement nourricier, ce qui se fait de plusieurs manières :
    • vis mon job : passer sa journée d’anniversaire dans un autre service
    • UP, université permanente, propose des cours pour le développement personnel (cours de langues, excel…). Se fait entre midi et deux ou le soir.
    • module découverte, pour apprendre des sujets divers sans forcément de lien avec l’entreprise. les locaux et les ressources de l’entreprise sont mis à disposition, elle paye les repas.
  • Gardien du temple. Quand la vision dérive, il la recentre sur ses valeurs

Bref

Cet article contient de nombreux mots clés mais ne donne pas vraiment de clés à mettre en oeuvre directement. En fait, on retrouve de nombreux ingrédients des recettes de Zobrist et de « Liberté et compagnie » dans de nombreuses entreprises libérées. Les détails concrets de leur implémentation sont à voir au cas par cas.

Un des éléments à garder à l’esprit, c’est de ne pas négliger l’importance de responsabiliser les employés, pas juste créer un contexte dans lequel ils sont libres.
La liberté sans la responsabilité, c’est l’anarchie. Au contraire, la liberté avec la responsabilité entraîne le bonheur et la performance.

Il ne faut pas remplacer le contrôle par l’absence de contrôle, mais remplacer les outils contrôlant et structurants par d’autres outils. L’autoévaluation est l’un d’entre eux.

Et quel que soient les processus que l’on crée, ne pas négliger de les remettre en cause régulièrement.

Il y a quelques temps, j’ai du filmer un écran pendant un long moment, plusieurs heures; comme il n’allait rien s’y passer pendant la majeure partie du temps, utiliser une application qui allait prendre plusieurs images par seconde n’était pas envisageable, car le fichier de sortie aurait rapidement atteint une taille trop grosse. De plus, j’avais juste besoin de voir en gros les moments où il y aurait de l’activité donc je n’avais pas besoin d’une telle précision. Une précision de l’ordre de la seconde suffisait largement.

J’ai donc opté pour un script shell, qui faisait une capture d’image par seconde, que j’ai ensuite assemblée, à une vitesse supérieure (plusieurs images par secondes). On appelle ce genre de vidéo un timelapse.

Divers articles m’ont aidé, mais c’est finalement celui-ci que j’ai mis en oeuvre car il est simple. Le processus est assez facile à reproduire sur une Ubuntu.

On commence récupérer les deux packages que l’on va utiliser, pour faire les captures puis l’assemblage :

1
$ apt-get install scrot mplayer

Pour faire les captures d’écran, on écrit le script shell suivant, qu’on lance et qu’on laisse tourner :

1
2
#!/bin/sh
while [ 1 ]; do scrot -q 100 $(date +%Y%m%d%H%M%S).jpg; sleep 1; done

Ce script prend une capture toute les secondes, et sauvegarde dans un fichier JPEG dont le nom correspond à la date formattée.

Une fois la capture terminée, on arrête le script et on liste les fichiers images dans un fichier, du plus récent au plus ancien :

1
$ ls -1tr *.jpg > files.txt

C’est l’occasion de découvrir de nouveaux paramètres pour ls !

    -1 permet d’avoir un nom de fichier par ligne (attention, c’est le chiffre « un », pas la lettre « l »)
    -t trie les fichiers par date de modification
    -r inverse l’ordre des fichiers

On assemble enfin les images avec mencoder, à raison de 20 images par secondes. Vous pouvez ou non ajouter un fichier mp3 directement pendant l’assemblage :

1
$ mencoder -ovc x264 -oac mp3lame -audiofile basket_case.mp3 -mf w=1400:h=900:fps=20:type=jpg 'mf://@files.txt' -o screenlapse.avi

Et voila. Prochaine utilisation de ce script lors de ma participation à une future Ludum Dare, peut être la 32ème ? Les timelapse de participants y sont monnaie courante.

Nous sommes aujourd’hui le premier décembre. Comme tous les ans, c’est le premier jour des calendriers de l’avent. Sur le web, de nombreux calendriers virtuels en profitent pour parler du web sur un principe simple : un jour = un article. Les articles sont généralement écrits par des auteurs de tous bord, et c’est l’occasion de découvrir de nombreux sujets.

Voici une petite liste des calendriers que je connais, et qui parlent de développement web, de prêt ou de loin :

24joursdeweb est le seul que je connaisse. Il parle du web en général, pas d’une techno en particulier. Tous les sujets sont abordés : développement, intégration, UX, accessibilité, bonnes pratiques…

24ways est son pendant en anglais. Même style d’articles, mais en anglais.

UXmas propose des articles sur le thème de l’UX (User eXperience).

24pullrequests fonctionne un peu différement. Il propose aux utilisateurs de contribuer à un projet open source différent chaque jour, en fournissant une plateforme qui incite à faire une pull request par jour.

Plus décalé, The Avengifs propose tous les jours un Gif rigolo.

Si vous connaissez un calendrier qui manque à cette liste, n’hésitez pas à le dire dans les commentaires !