L’image que les marketeux ont de l’informatique

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.

10 réponses sur “L’image que les marketeux ont de l’informatique”

  1. Je suis pleinement d’accord. L’implication des développeurs est trop souvent limitée, dans le sens où on leur demande de développer des projets et de la fermer. Ca entraine une diminution de l’intérêt apporté aux sources écrites, et donc une diminution de la qualité (en plus d’un turn over accru).

  2. J’en ai pleuré de rire sur la partie “La technique ne doit pas être un problème, alors il faut des développements configurables et évolutifs”. Je suis dans une boite de marketeux depuis un peu plus d’un an et la précédente, c’était la même base de départ. Sans vouloir ce terme péjoratif, je veux juste qu’elle a été fondé par des marketeux et garde un fort esprit de priorité au marketing. A l’inverse, avant, je bossais dans une boite d’ingénieurs (genre 1000 dev, 400 admin, 350 testeurs, 600 cdp divers et variés, 200 personnes à la BI pour 3500 employés sur le site où j’étais).
    La différence de culture est plus que violente. Tout ça pour dire que même si certains trouveront caricatural ton énonciation des faits, elle est finalement très réaliste.

    Ceci dit, dans une boite d’ingénieurs, on arrive vite aux mêmes problèmes finaux d’inertie. A l’inverse de tous les projets qui sont mal définis, là on arrive à une sur-définition ou plutôt une sur-validation des choses. On attend des validations d’une dizaines de responsables en tout genre et de tout domaine, certains valident d’autres chipotent, d’autres refusent. On modifie en conséquence pour prendre en compte les attentes, et là le premier groupe se met à refuser. Résultat : on perd un temps fou à concilier tout le monde. Pas forcément aussi destructeur pour le moral des développeurs, mais perte de temps flagrante pour la capacité à réagir aux nouveautés, aux changements de l’entreprise…

    Mieux vaut un combo bien dosé des deux esprits. Mais attention, ça peut aussi littéralement très vite partir en sucette. J’ai expérimenté ça aussi à mes dépens

  3. @MathRobin : Merci pour ce retour.

    Mais attention, je ne dis pas que les marketeux ont fondamentalement tort. À la base, leur métier de d’injecter la problématique client au cœur de l’entreprise, et c’est quelque chose de très important.

    Et je suis d’accord : une entreprise constituée uniquement de techos, ce n’est pas mieux 😉

  4. Je crois qu’on a assisté au même groupe de réflexion 😉

    100% d’accord avec ton constat.

    A mon sens la « culture start up » ça ne se décrète pas, ça se vit.

    Ca passe par des petits projets, menés par des petites équipes.

    Si ça fonctionne, je pense que ça peut se propager rapidement.

    On va essayer 😉

  5. Oui Jean-Benoît, je parle bien de cet atelier 😉

    J’ai une vision un peu extérieure à tout ça. Donc c’est facile pour moi de parler des startups en bien et des grosses boîte en mal, vu ma position…

  6. On peut faire le même constat en étant de l’intérieur 😉

    Au début je me suis fait la réflexion que tu devais découvrir un autre monde ^^.

  7. Un petit peu, c’est vrai 🙂

    J’ai notamment été étonné de voir que, dans mon « sous-groupe » de réflexion, les autres personnes semblaient focalisées sur les outils de commercialisation et ne s’intéressaient pas le moins de monde au produit lui-même. Mieux commercialiser l’offre actuelle, c’est effectivement important ; mais quand l’enjeu est de transformer l’entreprise, ce serait bien de réfléchir à ce qu’elle vendra à l’avenir.

  8. Super article très bien résumé et malheureusement très vrai !

    A mon sens la composante principale de l’esprit startup c’est « la prise de risque » et donc:
    – Investir dans les gens, projets avec un risque de fail
    – Mais viser des leviers important, des ruptures technologiques

    C’est valable pour le management mais aussi pour les employés qui vont risquer l’aventure si en retour il y a un levier possible.

    Le terme de « développeur » est presque devenu péjoratif en France: « petites mains qui font les choses » alors qu’outre Atlantic ce sont les « rock star » qui conçoivent et design les produits de demain.

    D’ailleurs dans les présentations zen US, le sujet est le produit, avec des infos techniques, un story telling et son ROI et non pas un écran de fumée marketing.

  9. Pourquoi est ce qu’ils se remettraient en question ? L’entreprise gagne de l’argent donc pour eux, c’est que ca fonctionne. Du coup, chacun reste sur ses positions.
    Bref, je suis d’accord avec ton article.

    Merci

  10. Tellement vrai !!!
    Personnellement, je pense qu’on manque aujourd’hui de personnes avec des doubles compétences qui permettraient de faire sauter les cloisonnements.

    Quel réalisme également sur les politiques d’investissements, notamment dans les grands groupes, où il faut exister … si tant et si bien, que chaque service développe le même projet dans son coin, sans qu’aucun aboutisse

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Notifiez-moi des commentaires à venir via email. Vous pouvez aussi vous abonner sans commenter.