Les grandes entreprises | Original, traduit par l'IA
Les grandes entreprises ressemblent beaucoup aux grands programmes. Pour une grande entreprise avec 100 000 employés et 50 000 sous-traitants, elles sont comme un grand programme avec 150 000 méthodes.
Dario Amodei a déclaré que la densité de talents est bien plus importante que le nombre de talents. Deux cents personnes très talentueuses peuvent battre 1 000 personnes talentueuses avec 800 personnes ordinaires.
Dario Amodei a également mentionné que les grandes entreprises ont tant de procédures et de processus parce qu’elles ne font pas confiance à leurs employés ou sous-traitants. Elles doivent donc vérifier et contrôler beaucoup de choses.
Une chose à propos des grandes entreprises, c’est qu’elles ont peur de faire des erreurs. Une raison est qu’elles ont tellement grandi pour valoir 300 milliards ou 1 000 milliards de dollars ; elles ont dû faire des tonnes d’erreurs et grandir à partir de cela. Cependant, lorsqu’elles réussissent, elles sont averses à prendre des risques et à faire des erreurs à nouveau.
C’est comme un grand programme qui n’aime pas les bugs et qui essaie d’éliminer tous les bugs, surtout les bugs de sécurité, en particulier dans les grandes banques.
Les startups sont rapides, mais les ressources d’une startup sont bien moins nombreuses, et la marque d’une startup n’est pas établie ; elles n’ont pas la confiance des grandes entreprises.
En Chine, les jeunes talents veulent encore aller dans les grandes entreprises après leurs études et se battent pour y parvenir. En Silicon Valley, il y a tellement de startups, certaines d’entre elles réussissent même dès le début avec juste des idées.
Certaines entreprises durent 20 ans et luttent encore, probablement retirées de la bourse, et certaines entreprises sont valorisées à 5 milliards ou 10 milliards de dollars alors qu’elles ont seulement quelques mois d’existence.
On dit que le Thinking Machines Lab de Mira Murati vaut 12 milliards de dollars lors de la levée de fonds initiale. Et Safe Superintelligence d’Ilya Sutskever lève 2 milliards de dollars pour une valorisation de 32 milliards.
Ainsi, utiliser le temps établi pour mesurer une startup n’est pas un bon indicateur ; il est préférable de la mesurer par ce qu’est l’équipe, qui sont les fondateurs et dans quel domaine ils se trouvent.
Dans ma startup en solo, il me suffit d’utiliser 1 minute pour déployer mon serveur backend et 5 minutes pour corriger un bug mineur et déployer. C’est direct et rapide. Pour les grandes entreprises, il faut 1 semaine pour préparer la demande de déploiement, obtenir les approbations des managers, faire le déploiement avec l’équipe IT et effectuer les vérifications de santé.
Bien que le temps réel passé puisse être de 8 heures, si nous le mesurons, cela reste 1 semaine entre la préparation du déploiement et la vérification finale de santé.
Pour corriger un bug mineur et déployer, cela prend deux semaines. Vous obtenez le ticket pour enquêter, faire l’analyse et les tests, puis la revue, fusionner le code, le signaler aux équipes de test pour qu’elles testent, et ensuite déployer.
Les grandes entreprises aiment imposer leurs politiques à toutes les équipes ou projets. Parce que pour une grande entreprise avec 200 000 personnes, ces politiques ou processus internes qui ne s’appliquent qu’à 10 000 personnes n’ont pas beaucoup de sens ou de résultat. Pour certains processus internes, les grandes entreprises doivent investir du personnel ou de l’argent pour développer des outils pour les soutenir. Donc, si cela ne sert qu’une infime proportion du personnel, le retour ne justifie pas l’investissement.
Un autre inconvénient des grandes entreprises est que souvent personne n’est puni pour les grosses erreurs.
Dans ma startup, j’ai obtenu un investissement de 500 000 dollars pour embaucher 9 personnes, et après 2 mois, j’ai dû les licencier et perdre cet argent. J’ai fait 50 petits projets logiciels avec des ingénieurs à temps partiel pour récupérer cet argent et le rendre à l’investisseur.
C’est un souvenir très intense et douloureux. Et cela m’a fait retenir cette leçon en permanence.
Dans un cas notable au sein d’une grande entreprise, il a été observé qu’il n’y avait pas de conséquences significatives pour les personnes impliquées. Certains cadres supérieurs et de nombreux employés récemment embauchés ont été licenciés. Il reste incertain si cela était lié à une embauche rapide et substantielle.
Un facteur contributif à ce résultat est la lourdeur et le nombre de processus au sein des grandes entreprises. Les ingénieurs qui étaient dans l’entreprise depuis six mois à un an n’ont pas pu faire de contributions significatives. Le calendrier comprenait généralement deux mois pour comprendre les bases, trois mois pour se familiariser avec les projets, trois mois à naviguer à travers des procédures ou des tests fastidieux, et enfin, deux mois de travail productif qui impactait les utilisateurs.
En supposant une journée de travail de huit heures, deux mois de travail productif réel n’ont pas donné de résultats substantiels. Le budget du département était épuisé, et la base d’utilisateurs ne s’est pas développée comme prévu, entraînant de nouveaux licenciements.
Il semblait que aucune leçon précieuse n’ait été tirée de cette expérience. Initialement, un groupe de managers avait décidé d’une stratégie d’embauche rapide et extensive, qui semblait inutile à l’époque. Blâmer l’ensemble du groupe de managers n’était pas réaliste, ni pratique de licencier uniquement ceux qui étaient dans l’entreprise depuis une courte période, surtout lorsque d’autres managers et responsables techniques faisaient partie de l’équipe depuis six à huit ans.
Le directeur général n’a pas beaucoup appris de la situation, car c’était juste l’un des trois départements sous sa supervision, et sa rémunération est restée inchangée. Même au sein de l’équipe, ceux qui n’étaient pas directement responsables n’ont pas pu tirer les leçons de l’expérience, écho aux remarques de Steve Jobs sur le conseil. Par conséquent, personne n’a absorbé la leçon nécessaire pour former une équipe exceptionnelle capable de livrer des résultats exceptionnels pour les utilisateurs.
Pour les startups, cela semble être un bien meilleur cas. Parce que c’est vraiment sérieux. Certains des fondateurs qui perdent ou échouent ont vraiment du mal, surtout les honnêtes.
Pour les individus intègres, il peut être profondément décourageant de perdre des fonds d’investissement substantiels, allant de millions à centaines de millions de dollars, et de se retrouver avec peu à montrer—peut-être juste un produit rudimentaire ou une base d’utilisateurs qui, malgré sa taille, génère peu de revenus.
Paul Graham a écrit un essai avant, Hiring is Obsolete.
Mais que font bien les grandes entreprises ? L’une est le long terme. Elles tendent à faire les choses pour le long terme. Pour certaines bonnes grandes entreprises, leurs conceptions de projet sont assez bonnes ; elles utilisent des microservices pour éviter l’erreur de devenir un grand programme monolithique après une décennie. Et elles ont des équipes de gouvernance pour créer certains cadres fondamentaux et unifier les pratiques de développement pour toute l’équipe.
Les processus ou procédures ne sont pas intrinsèquement mauvais. Mais ils rendent souvent les choses compliquées et lentes. Nous ne trouvons pas le format de code Java unifié désagréable parce qu’il existe un plugin Spotless ou Checkstyle pour aider. Ces plugins ont une bonne conception et sont faciles à utiliser.
Une autre chose est que les grandes entreprises tendent à créer certains outils ou projets pour un usage interne, pour les agents de front. Mais cette base d’utilisateurs est juste de quelques centaines ou 10 000. Cette base d’utilisateurs est très limitée.
Je pense que nous ferions mieux d’utiliser des outils externes à cette fin. Si un outil est vraiment génial pour une banque, il est probablement bon pour 200 banques. Et cela peut faire de cette entreprise une licorne.
Tiancheng Lou, fondateur de Pony.ai, dit que la raison pour laquelle les entreprises doivent être indépendantes est qu’elles sont plus efficaces. C’est vrai.
Et les grandes entreprises tendent à utiliser l’expérience pour récompenser les employés. Alors que le marché récompense le résultat ou l’exécution pour les équipes de startups. Ils sont en fait très différents.
Travailler dans les grandes entreprises, c’est comme apprendre à l’école. Vous progressez de l’école primaire au collège, puis à l’université. Dans les startups, cependant, il y a plus de hauts et de bas, et il y a plus de flexibilité lorsque vous passez d’une idée ou d’un marché à un autre.
Pour les grandes entreprises, le bénéfice d’être averses au risque est que leurs produits sont relativement stables sans bugs apparents ou temps d’arrêt. C’est bien.
Mais comme l’IA, en fait, beaucoup d’utilisateurs sont ok avec des produits qui ne sont pas si stables au début, comme DeepSeek. Nous savons que DeepSeek a eu beaucoup de problèmes autour de février-mars 2025 lorsqu’il a gagné beaucoup d’attention. Mais après un certain temps, il devient meilleur et aucun utilisateur ne semble avoir de problème avec cela.
Donc cela dépend. Parfois, pour les produits innovants, nous devons les mettre sur le marché rapidement, même s’ils ont quelques problèmes. Les utilisateurs peuvent comprendre.
Si nous pensons au processus, nous pouvons être plus prudents. Nous devrions mieux catégoriser nos types de déploiement. Certains types de changements sont ok à déployer rapidement, tandis que d’autres ne le sont pas. Pour les tests, nous devrions catégoriser quelles parties des tests nous devons effectuer pour les tests de régression du code modifié, et quelles parties nous ne devons pas. Il en va de même pour les vérifications SonarQube.
Dans les grandes entreprises, il est certain que de nombreuses vérifications, tests ou approbations sont inutiles. Nous pourrions laisser les ingénieurs faire leur travail, et puisque le système a tous les enregistrements, nous pouvons en sélectionner certains pour les examiner.
Nous devrions également éliminer toutes les approbations des managers. Quelle connaissance les managers ont-ils que les ingénieurs n’ont pas ? Cette connaissance pourrait-elle être écrite dans le code pour approuver ou rejeter les demandes automatiquement ?
Parce que tout est lent là-bas, les travailleurs sont peu susceptibles de changer les choses. Le passage d’un projet monolithique à des microservices pour un projet qui a fonctionné pendant une décennie peut prendre deux ans.
Pour le logiciel, le code et la logique sont étroitement liés, surtout dans les systèmes bien conçus. Ainsi, le développement, les tests ou la collaboration impliqués peuvent être substantiels.
C’est pourquoi le fait de faire évoluer une équipe soudainement ne fonctionne souvent pas. Si une architecture de microservices est faiblement couplée, alors le rendement de l’équipe peut être proportionnel au nombre de membres de l’équipe. Si un projet monolithique est fortement couplé, alors le rendement de l’équipe peut n’augmenter que de 30 % si nous doublons la taille de l’équipe qui y travaille.
En raison de son rythme lent, il peut parfois être difficile de déterminer si un employé ou un sous-traitant est incapable ou si le système est trop complexe et encombrant pour les nouveaux arrivants. Dans un cas que j’ai observé, quelqu’un était dans l’entreprise depuis quatre mois et n’avait accompli presque rien, changeant seulement quelques lignes de code pour soumettre une demande de fusion. De plus, la qualité du code était mauvaise car il ne le comprenait pas bien. Son anglais était également très faible, et il ne pouvait communiquer qu’en collant des captures d’écran et en utilisant un anglais basique pour poser des questions.
En ce qui concerne la stabilité, je vois que les grandes entreprises ont tendance à avoir plusieurs membres d’équipe travailler sur des tâches en double. Par exemple, pour la tâche A et la tâche B, elles n’assignent pas deux ingénieurs d’équipe à travailler séparément sur la tâche A et la tâche B. Au lieu de cela, elles font travailler les deux sur des parties de la tâche A et de la tâche B afin que ces deux ingénieurs sachent ce que fait l’autre. Cela rend l’équipe plus stable, car cela évite une situation où une seule personne connaît beaucoup de grandes parties du code et y travaille depuis plusieurs années sans collaboration. Ensuite, si cette personne quitte l’entreprise, personne d’autre ne peut y travailler.
Une autre chose que les grandes entreprises font bien est de maintenir la trésorerie et la discipline des profits. La raison en est qu’à mesure qu’elles grandissent, elles font souvent face à des crises financières substantielles. C’est probablement la chose la plus importante qu’elles priorisent. Elles ont appris cela à la dure et ont intégré ces pratiques dans leurs opérations. Même lorsqu’elles réalisent des profits de 10 milliards de dollars ou 30 milliards de dollars par an, elles continuent d’optimiser leur main-d’œuvre et de procéder à des licenciements.
L’un de mes collègues m’a dit que les grandes entreprises fonctionnent avec un monopole sur certains produits qui nécessitent beaucoup de main-d’œuvre ou de temps à construire. Cela a du sens. Elles ne comptent pas sur la vitesse mais sur leur taille, leurs ressources et leur marque.
Comment survivre dans les grandes entreprises ? L’une est de faire plus, moins parler. C’est ce que mon manager de livraison dans un fournisseur de services externalisés m’a dit.
La deuxième chose est de suivre ce que font les autres ; c’est sûr. Devenir un ingénieur moyen dans l’équipe est sûr, tout comme être une personne moyenne dans la rue—ni trop remarquable ni trop négligée, mais juste au milieu.
Je dois dire qu’il y a beaucoup de grandes entreprises. Certaines ont plus de 200 000 employés, tandis que d’autres en ont environ 20 000. Il y a aussi de bonnes grandes entreprises et des entreprises à faible performance. L’apparence ou la capitalisation boursière ne révèle parfois pas grand-chose. Elles peuvent augmenter considérablement en quelques années, comme Nvidia l’a fait récemment, ou elles peuvent s’effondrer soudainement, comme Credit Suisse.