C’est presque vrai, mais les équipes commerciales ou financières n’ont pas non plus vraiment ce pouvoir d’achat. Du coup, tout le monde finit par utiliser les outils autorisés par l’entreprise ou les offres gratuites, et doit en pratique convaincre son supérieur
Il faut vendre ça en expliquant que cela fait gagner du temps, rend les projets plus transparents, ou réduit la liberté
Si Excel est aussi répandu, c’est probablement en partie pour cette raison. C’est aussi l’outil le plus puissant que l’IT de l’entreprise autorise
Il suffit d’essayer d’obtenir l’autorisation d’installer WSL sur un PC en travaillant dans la vente ou la finance pour s’en rendre compte. Si les web apps sont populaires, c’est aussi parce que l’IT de l’entreprise doit déjà savoir qu’elles existent pour pouvoir les bloquer
Un responsable marketing peut peut-être payer Basecamp avec sa propre carte, mais pour faire entrer un outil auto-hébergé, il faut passer la politique IT du type « les ordinateurs, c’est nous qui les gérons, et la manière de travailler aussi », donc ça devient une bien plus grosse affaire
Excel est largement utilisé parce que, littéralement, tout le monde peut s’en servir. Contrairement à une base de données, ce qu’on crée y apparaît sous une forme visuelle directe
Il est inclus dans toutes les licences m365, et sa licence perpétuelle est longtemps restée relativement abordable
L’idée d’autoriser WSL à l’équipe commerciale donne surtout envie de demander si vous avez déjà travaillé avec de vrais commerciaux. Dans 99 % des entreprises, même les commerciaux les plus à l’aise avec la tech peinent déjà à envoyer une pièce jointe par email sans aide, donc on peut se demander ce qu’ils feraient avec WSL
Globalement vrai. Une entreprise n’approuve pas l’achat d’un livre à l’unité, mais elle approuve un abonnement à une plateforme de formation
Approuver tous ces petits achats représente trop de travail, et si personne ne les examine, on finit avec des abonnements inutilisés un peu partout ou avec beaucoup d’achats qui n’apportent pas grand-chose à l’entreprise
D’après mon expérience, les équipes commerciales pouvaient avoir de bons outils au niveau du département, mais leur pouvoir d’achat restait assez limité
En revanche, le marketing semblait avoir une marge de manœuvre bien plus grande, sans doute parce que son travail consiste justement à acheter toutes sortes de choses
Même un manager peut devoir vendre l’idée à un échelon supérieur pour faire approuver l’achat d’un outil, ce qui peut être pénible. 80 dollars par mois et par utilisateur, c’est pratiquement gratuit par rapport au coût du travail, mais cela reste toujours un frein
S’il est difficile d’acheter une application auto-hébergée, c’est parce que l’IT doit ensuite assumer les coûts de serveurs, de réseau et de stockage, l’installation, les mises à niveau, l’exploitation et le support, le SSO via AD, l’email, Slack, les sauvegardes et la restauration, l’export et la migration des données, ainsi que la cybersécurité
Une seule faille dans une application peut mettre en danger tout l’IT de l’entreprise, et même avec de l’isolation ou du zero trust, la surface d’attaque et les coûts de sécurité augmentent
En réalité, acheter une application auto-hébergée est la partie facile ; le difficile, c’est de la faire tourner de façon fiable tous les jours pendant toute la durée nécessaire au métier. Il y a aussi des cas où la loi impose de conserver les données longtemps
Même pour un outil demandé par l’IT métier, certaines équipes techniques peuvent peut-être en assurer une partie de la gestion, mais souvent elles n’ont pas le temps, ou ce sont des développeurs et non des administrateurs systèmes ou réseau
Au final, il faut soit utiliser un bac à sable séparé de l’IT de l’entreprise, soit renoncer à des commodités comme les sauvegardes et AD, soit l’implémenter et le maintenir soi-même en shadow IT
C’est aussi, à mon avis, l’une des raisons de la croissance du SaaS et du cloud : externaliser ces coûts
Si vous devez vous battre pour acheter un livre à 50 dollars, c’est sans doute que vous n’avez pas choisi la bonne entreprise
Cela dit, certains développeurs ont créé des comptes non officiels avec leur carte pour tester Notion en interne, puis y ont rédigé d’importants documents de cadrage avant d’en partager les liens
La moitié de l’entreprise a implicitement créé un compte pour les consulter, et le mois suivant le CFO a reçu une facture de 10 000 dollars
Les histoires expliquant pourquoi il ne faut pas donner de pouvoir d’achat aux développeurs commencent souvent comme ça
Ce n’est qu’un exemple de modèle tarifaire prédateur et de dark patterns
Si beaucoup d’entreprises SaaS proposent mal le prépaiement ou des options de plafond fixe, ce n’est pas un hasard. C’est presque de l’arnaque
Je ne vois pas qui a pu penser qu’un système où un simple clic sur un lien peut entraîner une facturation était une bonne idée. Et s’il n’y avait même pas de plafond mensuel raisonnable sur la carte, alors toute la configuration est absurde
J’ai du mal à croire que ce soit « le début des histoires où les développeurs perdent leur pouvoir d’achat »
Que ce soit pour des développeurs ou pour n’importe qui d’autre, acheter directement des outils peut souvent relever d’une optimisation locale au détriment de toute l’organisation
Par exemple, les outils se fragmentent, on ne peut plus retrouver l’information via une recherche unique, ou il faut se connecter séparément à des outils différents selon les équipes
Si chaque équipe gère de son côté des outils contenant la propriété intellectuelle de l’entreprise, cela devient un cauchemar de conformité quand on vise la conformité SOC
En revanche, acheter des livres ou des ressources de formation me paraît très bien
Pour avoir déjà décidé de plus de 100 millions de dollars par trimestre de dépenses en matériel, logiciels et services d’ingénierie, si vous créez un outil pour développeurs, vous devez d’abord faire en sorte que les développeurs actuels le trouvent extrêmement utile et le défendent fortement
Il faut éviter de déclencher les critères éliminatoires comme les contrats opaques, le lock-in, la sécurité et la confidentialité des données, ou encore l’intégration SSO/authentification
Le prix doit aussi être cohérent. Une tarification proportionnelle de façon linéaire à une variable quelconque risque souvent de ne pas tenir dans un tableur financier. Une facturation par développeur et par mois est facile à comprendre ; une licence flottante à l’échelle de l’entreprise est encore mieux ; et parfois un forfait illimité pour toute l’entreprise est plus adapté
Même dans ce dernier modèle, on peut toujours répercuter les coûts de consommation comme le calcul cloud et le stockage. Si le produit peut être déployé directement dans le compte cloud du client, cela résout aussi les problèmes de sécurité et de confidentialité des données
Il faut offrir des contrôles de coûts comme un plafond de facturation, un plafond d’usage, des limites sur les configurations pouvant générer une utilisation coûteuse, ainsi que des rapports d’usage suffisamment détaillés
Si tout se passe bien, des contrats pluriannuels avec engagement de dépense sont possibles. Il faut maintenir la fiabilité du service et faire des revues trimestrielles avec les grands clients pour mesurer leur satisfaction et identifier les besoins non couverts
Vous pouvez aussi proposer et facturer des services professionnels haut de gamme, comme un ingénieur dédié et du support. C’est très rentable, et parfois essentiel pour gagner ou conserver certains clients
Comme le produit peut être controversé en interne chez le client et que ses opposants peuvent faire échouer son adoption, des services professionnels prenant en charge l’intégration et l’implémentation initiales peuvent réduire l’intervention des gardiens de l’IT et permettre d’atteindre les vrais utilisateurs
Quand un client est fermement convaincu qu’il peut construire lui-même le produit, mieux vaut en général ne pas s’acharner à le vendre. Même si ce jugement est faux, vous pouvez peut-être gagner au début, mais perdre à la fin
Le point 7 sur construire soi-même ou acheter n’est généralement pas aussi binaire. Le cas le plus difficile, c’est souvent quand il existe déjà un produit interne et qu’on veut soit le remplacer, soit lui ajouter de nouvelles fonctionnalités
La vraie question est de savoir à quel moment évaluer le retour sur investissement du build vs buy
Acheter un produit dont le coût d’intégration est très élevé revient en pratique à le construire. L’intégration exige du temps de développement, et ce temps aurait pu être consacré à autre chose ou au produit lui-même
On aimerait que cela apparaisse pendant une intégration de preuve de concept, mais même à ce stade, il faut du temps de développeur pour l’exécuter
Cela dépend de l’entreprise. Une entreprise où j’ai travaillé auparavant avait pour politique : « Si c’est nécessaire pour faciliter le travail — livres, licences, voire matériel — achetez-le, point. Le coût de gestion lié à la prise de décision est plus élevé, donc l’approbation immédiate est la règle par défaut. »
Est-ce que les développeurs se sont rués sur les achats ? Non, ils ont acheté à peu près autant qu’avant cette politique. En pratique, la vie est devenue plus confortable.
En gros, les livres, licences et le matériel étaient considérés comme des consommables, au même titre que des stylos ou du papier. Cela peut généralement fonctionner pour de petits logiciels locaux comme un IDE.
Cela suppose qu’on fasse confiance aux développeurs pour leur donner les droits administrateur, ou que l’IT de l’entreprise puisse autoriser l’installation.
On peut donner un petit budget à chacun, ou gérer cela au niveau de l’équipe ou du département, mais dès qu’une intégration IT à l’échelle de l’entreprise devient nécessaire, ça marche mal.
Je ne dis pas que cette approche est mauvaise ni qu’elle est totalement impossible, mais une ruée soudaine sur les achats n’est pas le seul mode d’échec.
Sur 10 ou 20 ans, cela peut avoir un tout autre aspect. Une hausse des coûts lente et invisible peut s’accumuler, et une culture peut apparaître où ceux qui utilisent un peu moins doivent malgré tout acheter des choses pour ne pas donner l’impression que les autres gaspillent.
Il existe beaucoup de mécanismes subtils qui poussent à l’augmentation des coûts, donc il faut aussi des mécanismes qui poussent dans l’autre sens. À mon avis, le problème n’est toujours pas résolu.
On pourrait imaginer une limite de budget généreuse, tout en précisant clairement qu’il n’est pas obligatoire de tout dépenser, et en ajoutant une règle selon laquelle une partie du montant restant en fin d’année serait donnée à une bonne cause acceptable pour tous.
Quelque chose comme : « Vous pouvez acheter des livres. Mais souvenez-vous que ce livre retire 5 dollars du don aux poneys. » Si c’était pour les lamantins, je risquerais de devoir travailler sur un Chromebook.
Le problème, c’est quand les managers interviennent dans toutes les décisions. Les gens pensent que les managers sont là pour aider, mais ils créent plus de problèmes qu’ils n’en résolvent.
Au mieux, ils sont souvent incompétents ; il vaudrait mieux supprimer quelques postes de managers et utiliser leurs salaires comme budget discrétionnaire. Tout le monde y gagne.
Dans mon entreprise actuelle, quelques personnes au profil plutôt RH s’occupent de ce type d’achats. Il suffit d’envoyer par e-mail le lien vers le matériel ou le logiciel nécessaire, et c’est livré à domicile.
Je n’ai pas besoin de connaître les procédures de commande et de livraison de l’entreprise, et c’est de loin la meilleure approche que j’aie vue jusqu’ici.
J’ai vécu quelque chose de similaire. Tout le monde avait une carte d’entreprise et on nous encourageait à nous en servir.
J’ai rencontré ce problème une fois en tant que salarié. Je voulais un ThinkPad, mais la direction insistait pour me donner un Dell médiocre ; au final, j’ai obtenu le ThinkPad.
À part ça, quand je demandais des livres ou des outils, je les obtenais simplement, et même un clavier séparé coûteux passait.
Maintenant que je suis indépendant, j’achète simplement ce dont j’ai besoin. En réalité, il n’y a pas grand-chose dont j’ai besoin.
Il n’existe pas tant d’« outils de développeur » utiles au point de justifier la dépense, et il y en a encore moins qui valent vraiment la peine d’être intégrés à mon flux de travail. Avec le temps, ce dernier point est devenu de plus en plus important.
C’est ça, la vie en entreprise.
On m’a donné un Dell médiocre, il est tombé en panne, on m’a redonné un Dell médiocre, il est tombé en panne, puis encore un Dell.
On vous dit : « Nous avons un contrat uniquement avec Dell », et si vous demandez pourquoi ils ont signé un contrat avec Dell au départ, un silence s’installe, puis on sent que les cerveaux se mettent enfin à tourner.
On finit par comprendre que le meilleur moment de la vie, c’est quand le Dell tombe en panne. Il faut cinq jours pour traverser les couches de bons de commande et de politique interne avant qu’un nouvel appareil soit expédié, et pendant ces cinq jours on ne peut rien faire à cause des politiques de sécurité draconiennes de l’entreprise.
Alors, pendant cinq jours, on dort, on reprend contact avec ses amis, on redevient un être humain.
J’adore Dell. Je ne veux pas de ThinkPad.
Pour mon usage personnel, j’utilise un MacBook.
Si vous devez demander, c’est que vous n’avez pas l’autorité.
J’ai autrefois travaillé dans une filiale d’une société d’ingénierie, très orientée ventes.
Au début, on pouvait offrir sans problème un déjeuner à 100 dollars, mais pas acheter une carte à 30 dollars pour mon ordinateur.
À l’inverse, dans la maison mère, on pouvait facilement acheter pour 5 000 dollars d’équipement de test, mais il fallait remplir trois formulaires pour emmener quelqu’un dans un fast-food.
À la fin de mon mandat, dans les deux cas, il était pratiquement impossible de faire quoi que ce soit sans ces formulaires.
Beaucoup d’entreprises de développement d’outils qui ont réussi ont gagné de l’argent non pas en faisant du marketing auprès des développeurs, mais en faisant du marketing auprès de leurs supérieurs. C’est vrai dans la tech, mais aussi dans beaucoup d’autres domaines.
Je compatis totalement. Dans une grande entreprise tech où j’ai travaillé, j’avais besoin de disques durs pour quelque chose, et il était plus facile d’acheter une baie de disques à 5 000 dollars et d’en retirer les disques que de passer une note de frais de 200 dollars pour un simple HDD.
Dès qu’on essayait d’acheter quelque chose hors de son périmètre, cela devenait absurdement compliqué.
Plus récemment, une entreprise m’a dit : « Vous avez une carte d’entreprise, utilisez-la », et les EVP approuvaient les dépenses liées aux événements. Ce n’était pas courant, mais j’ai trouvé impressionnant qu’ils comprennent qu’il faut parfois couper court à la bureaucratie.
La prochaine fois que je ferai une note de frais ordinaire, j’ai l’impression que je vais devoir me battre avec la compta parce qu’un reçu de taxi de 20 dollars n’indique pas le point de départ ni la destination.
J’achète moi-même les licences logicielles et je les passe en charges dans mes impôts. C’est la meilleure façon d’éviter les fausses économies.
En trouvant des outils adaptés et peu coûteux puis en les achetant moi-même, j’ai obtenu des récompenses au travail, je suis devenu irremplaçable sur certains projets, j’ai eu des augmentations et j’ai pu choisir les missions que je voulais faire.
Ma licence Jetbrains en est un bon exemple. J’ai du mal à imaginer faire du refactoring de code sans elle.
Si l’entreprise cesse de réduire les coûts, j’aurai plus de concurrents en interne.
En théorie, c’est aussi possible dans le système fiscal britannique. Le formulaire de Self Assessment comporte une rubrique pour réclamer des frais professionnels non remboursés par l’employeur.
Un ancien employeur me remboursait à un faible tarif kilométrique, donc je déclarais la différence dans ma déclaration d’impôts.
Pour les logiciels, je ne sais pas exactement comment s’appliqueraient les critères déterminant si c’est une dépense admissible.
Moi aussi, je fonctionne ainsi depuis des années.
Comme la plupart des entreprises n’achètent pas les bons logiciels pour le travail, je suis devenu la personne la plus efficace de mon équipe, parce que je peux faire les choses plus vite et plus efficacement que les autres.
Dans beaucoup d’entreprises, si on vous surprend à faire ça, vous aurez de gros ennuis.
Je me demande comment les salariés américains en W2 exemptés font concrètement pour « le passer sur les impôts ».
Je me demande quels autres exemples il y a.
Si ça peut être déployé sur Azure, AWS ou Google Cloud, la donne change
On ne peut même pas acheter un crayon sans approbation, mais dans le cloud de l’entreprise, on peut dépenser des milliers de dollars sans que personne ne pose de questions
C’est là qu’opère la magie d’Amazon Marketplace. On peut y acheter des services qui ne sont pas d’AWS, tout en les faisant quand même apparaître sur la facture AWS et en les imputant aux engagements de dépense de l’entreprise
Exact. On avait demandé à un développeur de mettre en place un serveur FTP. C’était un administrateur Linux compétent, qui avait déjà fait ce genre de chose plusieurs fois sur un VPS à 10 livres
Mais cette fois, il a choisi un service AWS à plus de 1 000 livres par mois. Quand la facture de la carte est arrivée, ça a été un gros problème, et les frais du mois suivant étaient déjà bien engagés
Après ça, il a fallu renforcer les contrôles
Même chose pour moi. Faire en sorte que les bonnes personnes évaluent localstack ressemble à une bataille longue et difficile
Mais comme l’achat d’une licence entreprise pourrait être amorti immédiatement rien qu’avec les économies réalisées, je me sens obligé d’essayer, même si ce n’est pas mon vrai métier
Pour être juste, c’est aussi parce que personne n’a encore trouvé comment intégrer terraform apply dans un workflow d’approbation SAP
Un modèle économique où l’ingénieur est le décideur est tout à fait possible. Mais seulement pour des outils où l’ingénieur peut faire une optimisation locale sans effet direct hors de son périmètre
Le meilleur exemple, c’est l’IDE. Une entreprise peut autoriser ses ingénieurs à faire chacun leurs choix personnels d’IDE pour gagner en productivité, et l’impact global de l’ensemble de ces décisions peut rester acceptable. JetBrains le montre bien
Mais tous les outils ne sont pas de cette nature. Le billet original parle d’exemples qui relèvent de la seconde catégorie, comme Redis, Terraform ou AWS
Contrairement aux IDE, quand des choix individuels se propagent dans les bases de données, la gestion de l’infrastructure ou l’infrastructure cloud, cela devient problématique. L’entreprise doit alors maintenir une pile hétérogène, et un vendeur ne peut pas construire un contrat entreprise significatif simplement parce qu’une équipe a choisi Redis
C’est pourquoi un certain niveau de standardisation devient nécessaire. À ce moment-là, l’impact du choix et l’ampleur des licences deviennent suffisamment importants pour que non seulement les responsables engineering, mais aussi la finance, veuillent avoir leur mot à dire. Et à juste titre
Et à partir du moment où la finance entre dans la boucle, il faut justifier ses choix dans une langue difficile pour la plupart des ingénieurs
Mon pouvoir d’achat fonctionne comme ça. Je dis à mon manager : « Si on achète cet outil de développement, on peut économiser X heures de temps développeur »
Il suffit que X soit assez grand par rapport au prix de l’outil. Cette méthode marche plutôt bien, donc je l’utilise souvent, au point que mon manager commence maintenant à la regarder avec scepticisme
Il a raison d’être sceptique. Qu’il s’agisse d’un outil ou d’une refonte, surestimer les bénéfices est aussi courant que sous-estimer l’effort, et les deux sont probablement fortement liés
Ça ne veut pas dire qu’il n’existe pas d’outils utiles. Il y en a, mais c’est très rare
Je me demande combien de temps il faudra avant qu’un manager dise : « Si on additionne tous les outils dont tu as parlé ces trois derniers mois, ça fait économiser une année-développeur ; donc on va retirer un développeur de l’équipe tout en gardant le même travail et le même planning »
On peut aussi recevoir comme réponse : « Le temps développeur n’est pas un KPI, et que vous travailliez 160, 180 ou 200 heures par mois, le salaire est le même »
1 commentaires
Avis sur Hacker News
C’est presque vrai, mais les équipes commerciales ou financières n’ont pas non plus vraiment ce pouvoir d’achat. Du coup, tout le monde finit par utiliser les outils autorisés par l’entreprise ou les offres gratuites, et doit en pratique convaincre son supérieur
Il faut vendre ça en expliquant que cela fait gagner du temps, rend les projets plus transparents, ou réduit la liberté
Si Excel est aussi répandu, c’est probablement en partie pour cette raison. C’est aussi l’outil le plus puissant que l’IT de l’entreprise autorise
Il suffit d’essayer d’obtenir l’autorisation d’installer WSL sur un PC en travaillant dans la vente ou la finance pour s’en rendre compte. Si les web apps sont populaires, c’est aussi parce que l’IT de l’entreprise doit déjà savoir qu’elles existent pour pouvoir les bloquer
Un responsable marketing peut peut-être payer Basecamp avec sa propre carte, mais pour faire entrer un outil auto-hébergé, il faut passer la politique IT du type « les ordinateurs, c’est nous qui les gérons, et la manière de travailler aussi », donc ça devient une bien plus grosse affaire
Il est inclus dans toutes les licences m365, et sa licence perpétuelle est longtemps restée relativement abordable
L’idée d’autoriser WSL à l’équipe commerciale donne surtout envie de demander si vous avez déjà travaillé avec de vrais commerciaux. Dans 99 % des entreprises, même les commerciaux les plus à l’aise avec la tech peinent déjà à envoyer une pièce jointe par email sans aide, donc on peut se demander ce qu’ils feraient avec WSL
Approuver tous ces petits achats représente trop de travail, et si personne ne les examine, on finit avec des abonnements inutilisés un peu partout ou avec beaucoup d’achats qui n’apportent pas grand-chose à l’entreprise
En revanche, le marketing semblait avoir une marge de manœuvre bien plus grande, sans doute parce que son travail consiste justement à acheter toutes sortes de choses
Une seule faille dans une application peut mettre en danger tout l’IT de l’entreprise, et même avec de l’isolation ou du zero trust, la surface d’attaque et les coûts de sécurité augmentent
En réalité, acheter une application auto-hébergée est la partie facile ; le difficile, c’est de la faire tourner de façon fiable tous les jours pendant toute la durée nécessaire au métier. Il y a aussi des cas où la loi impose de conserver les données longtemps
Même pour un outil demandé par l’IT métier, certaines équipes techniques peuvent peut-être en assurer une partie de la gestion, mais souvent elles n’ont pas le temps, ou ce sont des développeurs et non des administrateurs systèmes ou réseau
Au final, il faut soit utiliser un bac à sable séparé de l’IT de l’entreprise, soit renoncer à des commodités comme les sauvegardes et AD, soit l’implémenter et le maintenir soi-même en shadow IT
C’est aussi, à mon avis, l’une des raisons de la croissance du SaaS et du cloud : externaliser ces coûts
Si vous devez vous battre pour acheter un livre à 50 dollars, c’est sans doute que vous n’avez pas choisi la bonne entreprise
Cela dit, certains développeurs ont créé des comptes non officiels avec leur carte pour tester Notion en interne, puis y ont rédigé d’importants documents de cadrage avant d’en partager les liens
La moitié de l’entreprise a implicitement créé un compte pour les consulter, et le mois suivant le CFO a reçu une facture de 10 000 dollars
Les histoires expliquant pourquoi il ne faut pas donner de pouvoir d’achat aux développeurs commencent souvent comme ça
Si beaucoup d’entreprises SaaS proposent mal le prépaiement ou des options de plafond fixe, ce n’est pas un hasard. C’est presque de l’arnaque
J’ai du mal à croire que ce soit « le début des histoires où les développeurs perdent leur pouvoir d’achat »
Par exemple, les outils se fragmentent, on ne peut plus retrouver l’information via une recherche unique, ou il faut se connecter séparément à des outils différents selon les équipes
Si chaque équipe gère de son côté des outils contenant la propriété intellectuelle de l’entreprise, cela devient un cauchemar de conformité quand on vise la conformité SOC
En revanche, acheter des livres ou des ressources de formation me paraît très bien
Pour avoir déjà décidé de plus de 100 millions de dollars par trimestre de dépenses en matériel, logiciels et services d’ingénierie, si vous créez un outil pour développeurs, vous devez d’abord faire en sorte que les développeurs actuels le trouvent extrêmement utile et le défendent fortement
Il faut éviter de déclencher les critères éliminatoires comme les contrats opaques, le lock-in, la sécurité et la confidentialité des données, ou encore l’intégration SSO/authentification
Le prix doit aussi être cohérent. Une tarification proportionnelle de façon linéaire à une variable quelconque risque souvent de ne pas tenir dans un tableur financier. Une facturation par développeur et par mois est facile à comprendre ; une licence flottante à l’échelle de l’entreprise est encore mieux ; et parfois un forfait illimité pour toute l’entreprise est plus adapté
Même dans ce dernier modèle, on peut toujours répercuter les coûts de consommation comme le calcul cloud et le stockage. Si le produit peut être déployé directement dans le compte cloud du client, cela résout aussi les problèmes de sécurité et de confidentialité des données
Il faut offrir des contrôles de coûts comme un plafond de facturation, un plafond d’usage, des limites sur les configurations pouvant générer une utilisation coûteuse, ainsi que des rapports d’usage suffisamment détaillés
Si tout se passe bien, des contrats pluriannuels avec engagement de dépense sont possibles. Il faut maintenir la fiabilité du service et faire des revues trimestrielles avec les grands clients pour mesurer leur satisfaction et identifier les besoins non couverts
Vous pouvez aussi proposer et facturer des services professionnels haut de gamme, comme un ingénieur dédié et du support. C’est très rentable, et parfois essentiel pour gagner ou conserver certains clients
Comme le produit peut être controversé en interne chez le client et que ses opposants peuvent faire échouer son adoption, des services professionnels prenant en charge l’intégration et l’implémentation initiales peuvent réduire l’intervention des gardiens de l’IT et permettre d’atteindre les vrais utilisateurs
Quand un client est fermement convaincu qu’il peut construire lui-même le produit, mieux vaut en général ne pas s’acharner à le vendre. Même si ce jugement est faux, vous pouvez peut-être gagner au début, mais perdre à la fin
La vraie question est de savoir à quel moment évaluer le retour sur investissement du build vs buy
Acheter un produit dont le coût d’intégration est très élevé revient en pratique à le construire. L’intégration exige du temps de développement, et ce temps aurait pu être consacré à autre chose ou au produit lui-même
On aimerait que cela apparaisse pendant une intégration de preuve de concept, mais même à ce stade, il faut du temps de développeur pour l’exécuter
Cela dépend de l’entreprise. Une entreprise où j’ai travaillé auparavant avait pour politique : « Si c’est nécessaire pour faciliter le travail — livres, licences, voire matériel — achetez-le, point. Le coût de gestion lié à la prise de décision est plus élevé, donc l’approbation immédiate est la règle par défaut. »
Est-ce que les développeurs se sont rués sur les achats ? Non, ils ont acheté à peu près autant qu’avant cette politique. En pratique, la vie est devenue plus confortable.
Cela suppose qu’on fasse confiance aux développeurs pour leur donner les droits administrateur, ou que l’IT de l’entreprise puisse autoriser l’installation.
On peut donner un petit budget à chacun, ou gérer cela au niveau de l’équipe ou du département, mais dès qu’une intégration IT à l’échelle de l’entreprise devient nécessaire, ça marche mal.
Sur 10 ou 20 ans, cela peut avoir un tout autre aspect. Une hausse des coûts lente et invisible peut s’accumuler, et une culture peut apparaître où ceux qui utilisent un peu moins doivent malgré tout acheter des choses pour ne pas donner l’impression que les autres gaspillent.
Il existe beaucoup de mécanismes subtils qui poussent à l’augmentation des coûts, donc il faut aussi des mécanismes qui poussent dans l’autre sens. À mon avis, le problème n’est toujours pas résolu.
On pourrait imaginer une limite de budget généreuse, tout en précisant clairement qu’il n’est pas obligatoire de tout dépenser, et en ajoutant une règle selon laquelle une partie du montant restant en fin d’année serait donnée à une bonne cause acceptable pour tous.
Quelque chose comme : « Vous pouvez acheter des livres. Mais souvenez-vous que ce livre retire 5 dollars du don aux poneys. » Si c’était pour les lamantins, je risquerais de devoir travailler sur un Chromebook.
Au mieux, ils sont souvent incompétents ; il vaudrait mieux supprimer quelques postes de managers et utiliser leurs salaires comme budget discrétionnaire. Tout le monde y gagne.
Je n’ai pas besoin de connaître les procédures de commande et de livraison de l’entreprise, et c’est de loin la meilleure approche que j’aie vue jusqu’ici.
J’ai rencontré ce problème une fois en tant que salarié. Je voulais un ThinkPad, mais la direction insistait pour me donner un Dell médiocre ; au final, j’ai obtenu le ThinkPad.
À part ça, quand je demandais des livres ou des outils, je les obtenais simplement, et même un clavier séparé coûteux passait.
Maintenant que je suis indépendant, j’achète simplement ce dont j’ai besoin. En réalité, il n’y a pas grand-chose dont j’ai besoin.
Il n’existe pas tant d’« outils de développeur » utiles au point de justifier la dépense, et il y en a encore moins qui valent vraiment la peine d’être intégrés à mon flux de travail. Avec le temps, ce dernier point est devenu de plus en plus important.
On m’a donné un Dell médiocre, il est tombé en panne, on m’a redonné un Dell médiocre, il est tombé en panne, puis encore un Dell.
On vous dit : « Nous avons un contrat uniquement avec Dell », et si vous demandez pourquoi ils ont signé un contrat avec Dell au départ, un silence s’installe, puis on sent que les cerveaux se mettent enfin à tourner.
On finit par comprendre que le meilleur moment de la vie, c’est quand le Dell tombe en panne. Il faut cinq jours pour traverser les couches de bons de commande et de politique interne avant qu’un nouvel appareil soit expédié, et pendant ces cinq jours on ne peut rien faire à cause des politiques de sécurité draconiennes de l’entreprise.
Alors, pendant cinq jours, on dort, on reprend contact avec ses amis, on redevient un être humain.
J’adore Dell. Je ne veux pas de ThinkPad.
Pour mon usage personnel, j’utilise un MacBook.
J’ai autrefois travaillé dans une filiale d’une société d’ingénierie, très orientée ventes.
Au début, on pouvait offrir sans problème un déjeuner à 100 dollars, mais pas acheter une carte à 30 dollars pour mon ordinateur.
À l’inverse, dans la maison mère, on pouvait facilement acheter pour 5 000 dollars d’équipement de test, mais il fallait remplir trois formulaires pour emmener quelqu’un dans un fast-food.
À la fin de mon mandat, dans les deux cas, il était pratiquement impossible de faire quoi que ce soit sans ces formulaires.
Beaucoup d’entreprises de développement d’outils qui ont réussi ont gagné de l’argent non pas en faisant du marketing auprès des développeurs, mais en faisant du marketing auprès de leurs supérieurs. C’est vrai dans la tech, mais aussi dans beaucoup d’autres domaines.
Dès qu’on essayait d’acheter quelque chose hors de son périmètre, cela devenait absurdement compliqué.
Plus récemment, une entreprise m’a dit : « Vous avez une carte d’entreprise, utilisez-la », et les EVP approuvaient les dépenses liées aux événements. Ce n’était pas courant, mais j’ai trouvé impressionnant qu’ils comprennent qu’il faut parfois couper court à la bureaucratie.
La prochaine fois que je ferai une note de frais ordinaire, j’ai l’impression que je vais devoir me battre avec la compta parce qu’un reçu de taxi de 20 dollars n’indique pas le point de départ ni la destination.
J’achète moi-même les licences logicielles et je les passe en charges dans mes impôts. C’est la meilleure façon d’éviter les fausses économies.
En trouvant des outils adaptés et peu coûteux puis en les achetant moi-même, j’ai obtenu des récompenses au travail, je suis devenu irremplaçable sur certains projets, j’ai eu des augmentations et j’ai pu choisir les missions que je voulais faire.
Ma licence Jetbrains en est un bon exemple. J’ai du mal à imaginer faire du refactoring de code sans elle.
Si l’entreprise cesse de réduire les coûts, j’aurai plus de concurrents en interne.
Un ancien employeur me remboursait à un faible tarif kilométrique, donc je déclarais la différence dans ma déclaration d’impôts.
Pour les logiciels, je ne sais pas exactement comment s’appliqueraient les critères déterminant si c’est une dépense admissible.
Comme la plupart des entreprises n’achètent pas les bons logiciels pour le travail, je suis devenu la personne la plus efficace de mon équipe, parce que je peux faire les choses plus vite et plus efficacement que les autres.
Si ça peut être déployé sur Azure, AWS ou Google Cloud, la donne change
On ne peut même pas acheter un crayon sans approbation, mais dans le cloud de l’entreprise, on peut dépenser des milliers de dollars sans que personne ne pose de questions
Mais cette fois, il a choisi un service AWS à plus de 1 000 livres par mois. Quand la facture de la carte est arrivée, ça a été un gros problème, et les frais du mois suivant étaient déjà bien engagés
Après ça, il a fallu renforcer les contrôles
Mais comme l’achat d’une licence entreprise pourrait être amorti immédiatement rien qu’avec les économies réalisées, je me sens obligé d’essayer, même si ce n’est pas mon vrai métier
terraform applydans un workflow d’approbation SAPUn modèle économique où l’ingénieur est le décideur est tout à fait possible. Mais seulement pour des outils où l’ingénieur peut faire une optimisation locale sans effet direct hors de son périmètre
Le meilleur exemple, c’est l’IDE. Une entreprise peut autoriser ses ingénieurs à faire chacun leurs choix personnels d’IDE pour gagner en productivité, et l’impact global de l’ensemble de ces décisions peut rester acceptable. JetBrains le montre bien
Mais tous les outils ne sont pas de cette nature. Le billet original parle d’exemples qui relèvent de la seconde catégorie, comme Redis, Terraform ou AWS
Contrairement aux IDE, quand des choix individuels se propagent dans les bases de données, la gestion de l’infrastructure ou l’infrastructure cloud, cela devient problématique. L’entreprise doit alors maintenir une pile hétérogène, et un vendeur ne peut pas construire un contrat entreprise significatif simplement parce qu’une équipe a choisi Redis
C’est pourquoi un certain niveau de standardisation devient nécessaire. À ce moment-là, l’impact du choix et l’ampleur des licences deviennent suffisamment importants pour que non seulement les responsables engineering, mais aussi la finance, veuillent avoir leur mot à dire. Et à juste titre
Et à partir du moment où la finance entre dans la boucle, il faut justifier ses choix dans une langue difficile pour la plupart des ingénieurs
Mon pouvoir d’achat fonctionne comme ça. Je dis à mon manager : « Si on achète cet outil de développement, on peut économiser X heures de temps développeur »
Il suffit que X soit assez grand par rapport au prix de l’outil. Cette méthode marche plutôt bien, donc je l’utilise souvent, au point que mon manager commence maintenant à la regarder avec scepticisme
Ça ne veut pas dire qu’il n’existe pas d’outils utiles. Il y en a, mais c’est très rare