Je vous pose la question : qui décide des technologies à utiliser dans votre équipe, dans votre département ou chez votre client ? Avez-vous déjà demandé à rencontrer la personne ou le consultant qui a recommandé telle ou telle technologie ? Est-ce que vous savez depuis combien de temps cet outil ou cette technique est utilisée ?

Tout irait bien si vous n’aviez qu’une seule vie. Si vous êtes développeur comme moi, vous développez des projets et vous participez au développement d’un produit ou d’un logiciel. Mais vous ne décidez de rien. Les choix techniques sont effectués par des contraintes de budgets, de temps, de ressources disponibles (10 développeurs Java pour le prix de 5, certifié Bio) ou encore parce que le Directeur a eu magiquement un abonnement au Golf de Versailles, ou une suite au Sofitel « All-Inclusive« .

Bref bienvenue dans la réalité : tu ne décides pas des technologies, toi pauvre développeur.

Si vous avez une deuxième vie après vos heures de travail, que vous participez de temps en temps à un Java User Group ou à une conférence, vous devez parfois être frustré. Le matin vous vous battez pour obtenir une deuxième instance Oracle, que vous aurez peut-être dans 3 semaines. Le soir, vous codez votre projet sur Cloud Foundry ou Cloud Bees. Vous lancez 10 serveurs sur Amazon, vous utilisez Node.JS ou Java. Et c’est fun. Et ça marche. Car vous travaillez pour vous faire plaisir et par curiosité.

Alors qui décide des technologies ?

Faut-il demander la permission ou s’excuser après coup ? Comment structurer dans une entreprise les demandes de changements et d’innovations ? Comment diriger d’une main tout en ne fermant pas la porte à l’innovation ?

Avant tout, regardons ce qu’il se passait il y a quelques années, au XXème siècle. Les choix techniques étaient effectués par le top management. Le Directeur ou la Responsable de Produit pouvaient décider des technologies. J’ai entendu par exemple le témoignage d’une développeur, qui raconte que sa grosse entreprise a décidé de coder un langage et une VM pour faire des téléphones multi-média. Au moment où le top managment doit prendre une décision et l’assumer, décider de coder sa propre VM est peut-être plein de sens. Mais comment ensuite changer et prendre une technologie comme Android ? Même si le développeur souhaite changer de technologie, est-ce possible ?

Ce qui semble acquis aujourd’hui c’est l’énorme pouvoir de décision du Développeur par rapport aux années 90. La pyramide s’est renversée, et les choix techniques sont de plus en plus portés par le Développeur. Il y a même parfois un décalage entre ce que pense savoir le top management d’une entreprise et la réalité du terrain. Il est de moins en moins rare de voir des projets développés sans l’aval d’une quelconque hiérarchie.

Manager : validez rapidement

Lorsque les choix technologiques ne sont pas validés rapidement par des personnes expérimentées, votre projet court un danger important.

Peu importe la hiérarchie. Si vous voyez arriver une équipe dans votre bureau avec un superbe framework, demandez à voir quelque chose qui tourne. Demandez à regarder le code, sondez dans votre réseau afin de valider que vous pourrez trouver des développeurs. Interrogez les SSII qui travaillent avec vous. N’écoutez pas l’enthousiasme, regardez le nombre de hits sur Google lorsque vous tapez le nom de ce bel outil. Y-a-t-il des forums ou des listes de diffusion pour trouver de l’aide ? Est-ce que l’éditeur a les reins solides ? Bref ce que vous faîtes déjà. Déléguez simplement le choix, afin de donner aussi sa chance. De toutes les façons, vous développez en méthodes Agiles non ? Donc au pire, au bout de 2 ou 4 semaines, vous pourrez changer votre fusil d’épaule non ?

Développeur : soyez simple et professionnel

Lorsque vous êtes développeur, vous devez être le plus professionnel possible. Vous pouvez après tout coder une démonstration ou une partie du projet avec ce nouvel outil. Mais donnez-vous une limite. Si au bout de 3 jours vous n’avez pas réussi à construire ces écrans, que vous n’avez pas trouvé beaucoup d’articles ou d’aide sur Internet, arrêtez. Vous ne trouverez pas assez vite de l’aide et des ressources. Peut-être que votre choix n’est pas encore assez mature. Peut-être qu’il est en déclin. Respirez un coup, effacez votre code, et allez prendre l’air. Vous vous souviendrez que l’on juge de la qualité d’une technologie ou d’un outil sur la capacité à réaliser un logiciel qui marche dans un temps limité pour un budget fixe.

Quelques observations sur les méthodes de décision

Alors qui décide de vos technologies ? Si vous êtes une Banque, qui décide du langage de programmation de vos automates de trading ? Si vous êtes une Startup, qui décide du choix de framework ? Si vous êtes un éditeur, qui sélectionne la plateforme cible ?

Le Client Final pense que la technologie n’est pas son cœur de métier. C’est ce que pense peut-être une Banque. Or venez couper l’informatique une journée dans une Banque de Finance, elle fera faillite. Le choix des technologies est essentiellement fait avec l’idée de gagner encore plus en dépensant moins. Le côté « trendy » n’a aucun intérêt. Il est vital et important de prendre des technologies pérennes, qui seront encore sur le marché dans 3 ans. Bien souvent les développeurs sont des externes. Il faut donc qu’il soit facile de trouver des développeurs sur le marché avec des SSII.

Une Startup a un gros souci : trouver des développeurs. Regardez-moi dans les yeux et répondez-moi honnêtement : est-ce que vous êtes prêt à faire une croix sur vos 10 jours de RTT, votre prime annuel, le CE qui permet d’emmener les petits chez Mickey, le nom ronflant que vous portez, les avantages et la sécurité pour aller travailler dans une petite structure qui vous payera 15% de moins ?

J’espère que quelques uns ont répondu oui.

Une jeune pousse doit effectuer ses choix technologiques sur plusieurs critères : facilité à trouver de bons développeurs, rapidité d’exécution et coût d’exploitation limité. Cela fonctionne si et seulement si vous avez un excellent CTO. Cela fonctionne aussi si les fondateurs embauchent des développeurs au lieu de payer des stagiaires. Ne rêvez pas, votre site de ventes de coupon de réduction ne marchera pas s’il est codé par des stagiaires. Ne rêvez pas, votre idée est peut-être géniale mais pour l’instant elle ne vaut rien, tant que vous n’aurez pas fait coder une ligne de code. Et là, le choix technologique, ce ne sera pas vous. Ce sera le Développeur. Comprenez bien une chose : votre réussite dépend du bon choix des Développeurs.

Enfin un éditeur doit s’intégrer dans un écosystème. Les choix technologiques sont exclusivement effectués par les Développeurs, et validé par les investisseurs. Mais le marché décide bien plus souvent. Vous ne vendrez pas de Java à la Société Générale comme vous ne vendrez pas de .NET chez Reuters. Chaque éditeur et chaque client a sa propre culture. Vous ne pouvez pas avoir 600 développeurs sans stratégie de recrutement, de formation et de plan de carrière. Donc de technologies.

Si vous êtes indépendant, vous avez le choix de vos technologies. Vous faîtes ce que vous voulez. Vous assumez les conséquences et la prise de risque, avec cependant une très grande liberté. Vous avez vraiment le choix car vous décidez ou non de travailler pour tel client ou telle mission. Bien entendu, si vous voulez vous aussi prendre des vacances, pouvoir emmener les enfants chez Mickey et avoir l’esprit tranquille, vous ne pouvez pas choisir n’importe quelle technologie.

Mais au moins vous avez le choix.

12 réflexions sur « Qui décide de vos technologies ? »

  1. > Regardez-moi dans les yeux et répondez-moi honnêtement : est-ce que vous êtes
    > prêt à faire une croix sur vos 10 jours de RTT, votre prime annuel, le CE qui
    > permet d’emmener les petits chez Mickey, le nom ronflant que vous portez, les
    > avantages et la sécurité pour aller travailler dans une petite structure qui
    > vous payera 15% de moins ?

    OUI !

  2. Je suis assez d’accord avec toi. Mais tout dépend de l’expérience des développeurs. Lorsque tu débarques dans une équipe, un groupe, tu vas essayer de t’intégrer et de comprendre leur choix techniques, tu ne peux pas tout changer et mener une révolution en un instant. Avec l’expérience et les années dans l’équipe, le développeur peut gagner une certaine aura auprès des décideurs et apporter des suggestions qui seront écoutées et acceptées (dans certaines limites, il est évident que si le standard de l’entreprise c’est Oracle, tu ne vas pas utiliser un autre SGBD sans avoir de bonnes raisons).

    Quand à la Société Générale, il n’y a vraiment aucun problème en ce qui concerne le Java 😉

  3. Un point que je n’ai pas vu mentionné et qui est souvent à l’origine des choix de « socles » de framework: l’exploitation en production.
    Devops n’est pas en place dans toutes les structures (loin de là) et souvent les équipes de productions sont complètement séparées des équipes de dev.
    Dans un gros SI, les équipes de productions doivent gérer des centaines de serveurs et d’appli. Ils ont déjà assez de problème avec les logs écrits n’importe comment et respectant des formalismes différents dans chaque appli, alors ils demandent à réduire les sources possibles de problèmes : version de plateforme (jvm ou .net) unique, version de serveur d’application limitée et autant que possible, versions de frameworks identiques d’une appli a une autre.
    du coup on créé des « cibles » technique, validées par plusieurs équipes et forcément ça prends beaucoup de temps entre le moment où la « cible » est créée et celle où elle est effectivement disponible.

    Dans les faits ça pose plus de problème qu’autre chose : migrer vers la nouvelle cible est généralement assez coûteux, du coup les projets ne le font pas tout de suite, voir jamais. Ils ratent une première cible, puis une seconde, et la production se retrouve a gérer des environnements complètement obsolète sans chemin de migration possible.

  4. Le choix d’une technologie, comme toute forme de choix, devrait être raisonnée: quelle technologie apportera le plus de valeur dans le temps?

    Il n’est généralement pas difficile de trouver une bonne réponse (plusieurs bonnes réponses pouvant coexister), en utilisant des critères objectifs comme les qualités intrinsèques de la technologie (capacités de présentation, performance, interopérabilité…) ou qualités extrinsèques (coût, outils disponibles, vitesse d’évolution de la technologie, connaissance/opinion des développeurs sur la technologie…).

    Les qualités et limites de la technologie doivent être mises au regard de la mission à conduire, une technologie pouvant plus ou moins bien se prêter à un certain type de développement.

    Mais, comme beaucoup de choix effectués en entreprise, le choix d’une technologie est souvent plus le résultat d’une préférence humaine irraisonnée que d’une analyse. L’article cite des choix de managers induits par les « cadeaux » que ces derniers reçoivent: c’est amusant, sauf quand cela se produit vraiment (et j’en ai vus). Mais il est, à mon avis, un choix encore plus dangereux que celui fait par les managers: c’est le choix fait par les développeurs.

    Les choix faits par les développeurs sont souvent restreints aux technologies qu’ils connaissent et ont déjà utilisées. Ce n’est pas étonnant: un être humain, s’il reçoit du succès dans une activité, aura une tendance à reproduire le comportement qui lui a donné ce succès. Et la « tractabilité du media », comme dit Fred Brooks dans « The Mythical Man-Month », rend le développeur encore plus sujet à cet effet.

    Ainsi, un développeur ayant produit une application en PHP jurera ses grands dieux que PHP est l’une des meilleures technologies possibles pour une application (même si le projet, cette fois, requiert du temps réel, des capacités graphiques poussées, de la performance et qu’il faudra déployer l’application sur 10 postes max: PHP est LA solution, ma brave dame). Et bien sûr, je parle de PHP comme j’évoquerai Java, VBA ou Scheme.

    C’est l’effet pervers du succès et de l’expérience. Zéro connaissance, c’est l’innocence. Un peu de connaissance, c’est un risque élevé d’obscurantisme. Et beaucoup de connaissance, ce n’est pas encore la sagesse.

    Les développeurs, comme les managers, peuvent donc faire des bons et des mauvais choix. Les bons choix sont ceux qui sont informés et raisonnés, et sont généralement la production de personnes ayant pris des baffes et s’en étant relevé. Les mauvais choix sont souvent personnels et irraisonnés, et la production de personnes n’ayant pris que peu de baffes (se protégeant trop, ne prenant pas assez de risques) et désireux de ne pas en prendre plus (donc exploitant ce qu’ils connaissent et n’explorant pas ce qu’ils ignorent).

  5. A propos de la SG, c’est grand comme groupe et certaines entités sont moins rigides que d’autres. Ca va te plaire, il y a un certain Romain L qui est train de vendre Play!
    Il ne faudrait pas que les gens croient qu’il n’y a pas de java à la SG, c’est déjà assez difficile comme ça de trouver de bons développeurs java…

  6. Dans la SSII où je travaille, du moins dans l’agence de Lyon, il semble qu’une décision ait été prise par la direction sur les technologies à utiliser. Je dis « il semble » car aucune communication officielle (ni officieuse d’ailleurs) n’a été effectuée à ce sujet. Sans vraiment se poser la question de savoir de quelles compétences elle dispose actuellement, l’essentiel, pour ne pas dire la totalité des avant-ventes sont faites sur du .NET.

    En un an que je suis arrivé sur Lyon, le « plateau » qui était essentiellement Java, n’a vu qu’un seul projet Java de 3 mois rentrer. En revanche, plusieurs « gros » projets Java se sont arrêtés faute de budget client. Et là débarque un gros projet .NET pour lequel nous n’avons / n’avions pas les ressources / compétences.

    Mes collègues, développeurs Java, se sont retrouvés sur des projets PHP, des TMA, des études, … bref, là où on pouvait les faire patienter avant de les envoyer en formation … .NET! Les équipes se dépeuplent de leurs développeurs Java, forcés d’abandonner leur techno de prédilection, celle dans laquelle ils souhaitaient se spécialiser et devenir très bons, s’il ne l’étaient pas déjà.

    Des projets Java, sur Lyon, il y en a. En revanche, la décision de la direction de partir sur du .NET s’est faite sans prendre en compte les compétences actuelles de leurs développeurs. Développeurs qui sont forcés de suivre alors qu’ils aimeraient capitaliser sur un sujet, consolider leurs compétences et ne pas être baladés d’une techno à l’autre tous les 3 mois sans jamais devenir bons, voir très bons, dans un domaine précis.

    Chez nous, c’est la direction qui impose les technos… et les développeurs subissent.

  7. Qui aurait fait le pari d’Android, il y a 3ans, quand Google venait tout juste de racheter la techno ? Aujourd’hui, le choix peut être plus simple (quoi qu’il existe des WebOS, Meego et j’en passe).

  8. Julien, votre commentaire est amusant.
    Quand j’étais en Master 2, il y trois ans justement, une des entreprises qui est venu nous parler pour faire de la pub pour attirer les stagiaires nous a dit : « On prend le pari que Android sera majoritaire sur les téléphones d’ici quelques années ».

    Ils ont eu le nez creux chez Camineo.

    Je suis malgré tout parti en stage chez un grand compte, qui payait beaucoup mieux, et j’ai dévoré des BD toute l’année grâce à leur CE.
    🙂

  9. « Vous vous souviendrez que l’on juge de la qualité d’une technologie ou d’un outil sur la capacité à réaliser un logiciel qui marche dans un temps limité pour un budget fixe. »
    C’est une affirmation absolue qui mériterait contraste.
    Réaliser un logiciel
    – qui marche approximativement
    – et donc la conception/réalisation ont été guidées/bridées par les limitations des technos sous jacentes
    – qui devra être ré écrit le jour où je mettrai le doigts sur une limitation que l’on ne peut contourner et qui aboutira à l’adoption d’une toute autre techno
    – qui devra être ré écrit car la techno mourra 3 ans plus tard
    ne m’intéresse pour la coup, mais alors pas du tout.

    La qualité d’une technologie, d’un framework, et même de vos livrables ne peuvent s’apprécier que dans le temps, par le cout de la maintenance, la facilité de le faire évoluer, la qualité des messages d’erreur et leur gestion mais certainement pas par le fait que ça vous permet de livrer la V1 rapidement, ça c’est pour le prototypage, pas pour la prod.

  10. @Patricio : Je ne pense pas que la rapidité de développement signifie systématiquement « mauvaise qualité ». Au contraire, en faisant moins de métier, en se concentrant uniquement sur l’essentiel, et en utilisant un outil simple, le problème de la pérennité, de l’évolution de l’application et de la maintenance est traité rapidement, dès les premières semaines.

    La qualité d’une techno se juge aussi par la capacité à former des développeurs rapidement sur celle-ci. Or l’empilement de différents frameworks ne rend pas ce travail plus facile. Je réitère donc mon affirmation : pour un budget fixe dans un intervalle de temps limité, que peut-on produire avec une qualité industrielle ?

  11. @Nicolas
    je pense que, de manière sous jacente, on est tous les 2 convaincus que le problème principal est celui de la formation des équipes. Là je te rejoins totalement.
    Ce n’est pas parce que le permis de conduire est difficile et couteux à passer que l’on doit se rabattre trop rapidement sur les voitures sans permis, (ou pire conduire sans permis…), je trouve le parallèle intéressant.
    La rapidité de développement n’est pas synonyme de mauvaise qualité, ce n’est pas ce que je dis mais le meilleur moyen d’être rapide est d’être compétent sur des socles robustes et pérennes (je ne présage de rien quant à telle ou telle solution). La coût d’une appli se juge sur le long terme, il faudrait (mais je n’y crois pas un instant) cesser de se baser sur la première mise en prod.

    J’insiste, je n’ai pas la solution, c’est une réalité que les développeurs n’ont pas les formations qu’ils mériteraient d’avoir régulièrement. La faute à qui? au marché hyper concurrentiel je pense.

    Mais je confirme aller à l’encontre de ton affirmation, en toute amitié :). D’ailleurs qu’est ce qu’une qualité industrielle? Qui plus est, si je vais voir mon concessionnaire en lui disant « j’ai un budget limité mais je voudrai votre jolie berline efficace avec son beau moteur et qui consomme rien, qui tombera jamais en panne », je pense qu’il me demandera soit d’économiser, soit de me rabattre sur un modèle de moindre qualité.

    La compétence au coeur des débats plutôt que les parades pour contourner le défaut de formation.

  12. Salut,

    La lecture de l’article me fait penser quelque part à l’un des aspect du commercial : identifier les chemins de décision pour faire accepter ce que l’on a à vendre. Cela dit, article intéressant, mais à la SG, on commence à y voir du java, sisi, je t’assure 🙂

Les commentaires sont fermés.