Cette semaine, j’ai fait partie d’un groupe de réflexion au sein d’une grande entreprise. Ce groupe rassemblait des gens d’horizons différents, et le but était de trouver des solutions pour faire évoluer la culture de cette entreprise. Comme toutes les grosses boîtes, elle est devenu un énorme navire difficile à manœuvrer et qui a du mal à être réactif à cause de toute l’inertie subie en interne.

Pour faire simple, cela tenait en une phrase :

Ramener la culture start-up dans l’entreprise.

La réunion de travail a été démarrée par le directeur technique de cette société. Un gars très intelligent qui a déjà travaillé dans plusieurs startups. Dans toute son analyse, je vais juste vous citer quelques points, car ils sont importants pour la suite :

• Les effectifs techniques sont constitués de plus de chefs de projets et assimilés (MOA et MOE confondues) que de développeurs.
• Les développeurs sont majoritairement des prestataires.
• La communication est difficile entre les différents métiers (technique, marketing, commercial).

Le but de l’exercice était donc de définir les grandes lignes de ce qu’il fallait faire pour casser les « silos », afin de rétablir de la transversalité dans les projets. Tout le monde connait ce phénomène : les marketeux définissent une offre ou une fonctionnalité, les commerciaux déterminent comment ils vont la vendre, et les techniciens développent. Sauf que tout le monde sait que ça ne fonctionne pas. Enfin, tous les informaticiens le savent.

Pourquoi cela ne marche pas ? Simplement parce que le développement informatique n’est pas une commodité (pour faire un barbarisme à partir du terme anglais commodity). À ce sujet, je vous conseille de lire cet article (en anglais).

Durant cet atelier, un certain nombre de pistes ont été exprimées. Je ne vais naturellement pas tout dévoiler ici, mais les idées les plus importantes étaient aussi les plus évidentes :

• Diminution du nombre de « chefs » par rapport aux « exécutants ». Pour ma part, j’avais même préconisé de diviser les effectifs de l’entreprise par 4.
• Utilisation de cycles itératifs courts et organisation basée sur des méthodes agiles.
• Constitution de groupes de projets temporaires, regroupant des personnes d’horizons divers, avec intégration de tous à l’ensemble des étapes (les développeurs réfléchissent avec les marketeux dès le début, les commerciaux participent à toutes les évaluations d’itération, etc.).
• Internalisation des compétences, pour ne plus risquer de voir disparaître des compétences-clés à la fin d’un contrat de prestation.
• Encourager l’innovation interne et l’intrapreneuriat par des programmes de veille technologique et de R&D.

Cet atelier était riche et intéressant, notamment parce que des gens très différents y participaient.

Par contre, ce dont je veux vous parler ici, c’est que quelque chose m’a quand même frappé. Les idées que j’ai listées plus haut étaient partagées par tout le monde, en tout cas théoriquement. Nous étions tous fiers d’avoir convergé sur ce qui nous semblait être de bonnes pistes de travail.
Malgré tout, j’ai entendu par la suite des remarques qui m’ont fait me dire que certaines personnes étaient passées à côté de quelque chose, et qu’elles ne comprenaient définitivement pas nos métiers.

Voici quelques-unes de ces remarques.

“Chaque euro investi doit l’être intelligemment”

Bon, cette phrase n’est pas spécialement problématique quand elle est sortie de son contexte. Mais là, l’idée générale était globalement de dire qu’à partir de maintenant il fallait bien réfléchir aux investissements informatiques.

Ce qui veut dire que jusque-là l’argent était dépensé à tort et à travers ?

Soit c’est vrai, et il faudrait peut-être commencer par là ; soit c’est une grosse connerie, qui montre bien que chacun pense qu’il fait des investissements intelligents mais que tous les autres sont des gros débiles.

“La technique ne doit pas être un problème, alors il faut des développements configurables et évolutifs”

J’avoue que celle-là m’a bien fait marrer. Tout le propos de cet atelier tournait autour de l’esprit startup, des méthodes agiles, de la réactivité.

Ce que ça implique, c’est de développer rapidement les choses qui sont correctement spécifiées, et de les améliorer de manière itérative au fur et à mesure des besoins, en réalisant les refactorings nécessaires.

Là, c’était le retour grandiose du marketeux aveugle aux idées grandiloquentes : «Nous ne savons pas quelles sont les demandes qu’on va exprimer à l’avenir. Par contre, nous savons que nous sommes susceptibles de demander n’importe quel truc qui nous traversera l’esprit. Alors plutôt que de faire rapidement un SI qui réponde précisément à notre besoin immédiat, on préfère que vous passiez dès maintenant beaucoup de temps à prévoir nos futurs délires. Évidemment, on trouvera toujours que ça prend trop de temps, sans jamais reconnaître notre part de responsabilité. Et on s’arrangera pour que votre truc super-évolutif ne permette pas de faire ce qu’on vous demandera dès l’an prochain…»

Et après, on s’étonne d’avoir des clivages avec les équipes techniques qui pestent contre des spécifications incomplètes, les équipes fonctionnelles qui casse du sucre sur le dos des développeurs qui sont des bras cassés, et les utilisateurs qui traitent tout ce petit monde d’incompétents.

“Je rachète ou j’outsource” et “On va faire appel à Bangalore ?”

La première phrase m’a fait rigoler, parce qu’elle résulte d’une bonne volonté. Si certaines compétences (fonctionnelles, commerciales ou techniques) sont absentes de l’entreprise, il peut être une très bonne idée d’acheter des petites sociétés qui les possèdent. Ainsi, l’entreprise gagne ces compétences et peut les utiliser à son compte pour attaquer de nouveaux marchés.

Par contre, mettre au même niveau la prestation de service est une erreur très répandue chez les non-informaticiens, et profondément erronée. Payer des prestataires pour réaliser un développement, c’est utile quand on manque de “force de frappe” ; mais quand il s’agit d’attaquer un domaine nouveau, ou d’aborder un contexte innovant, c’est une gabegie sans nom. Il est important d’accroître les compétences internes de l’entreprises, sinon le développement n’a pas d’autre pérennité que celle de se lier au prestataire pour une longue durée.

La seconde phrase était plus dérangeante, parce qu’elle faisait partie d’une conversation que j’avais avec un jeune marketeux. Nous avions bien établi la nécessité pour l’entreprise d’augmenter ses compétences de pointe internes ; nous avions aussi défini clairement la nécessité d’injecter de l’esprit startup dans l’entreprise. Et malgré ça, le gars me disait qu’il était certain que certaines choses pouvaient être outsourcées en Inde sans problème.

J’ai essayé de lui faire comprendre mon point de vue, mais sans succès. Ça me semble pourtant évident. Quand une entreprise veut promouvoir l’innovation, il est primordial que les connaissances qui y sont liées restent dans l’entreprise. Non seulement cela permet d’envisager les innovations suivantes plus facilement, mais cela réduit les risques de perte de compétence lorsque les prestataires s’en vont.

Mais la discussion tournait en boucle. Le gars restait sur l’idée que l’entreprise aurait toujours tellement de projets à réaliser que cela nécessiterait plus de ressources que celles disponibles en interne. Alors que ma vision − résultat direct de mes années de carrière dans des startups − est que si l’entreprise n’a pas les ressources nécessaires pour effectuer tous ses projets, c’est qu’il faut juste définir correctement les priorités. Souvent l’entreprise a tellement de projets que ça devient la course pour tout faire, sans plus vraiment se demander s’ils sont tous nécessaires. Quitte à diminuer la qualité de leur réalisation.
À plus forte raison, si on pense que tous les projets sont importants, ne pas les maîtriser de bout en bout et ne pas en internaliser la connaissance n’est pas plus malin. C’est la logique de ceux qui pensent avec leur montre plutôt qu’avec leur tête.