Le cout de la PROD
L'enfer bureaucratique des grosses boîtes existe pour une raison.
Pas toujours une bonne raison. Mais une raison quand même.
Un post d'@evan boissonnot méritait une réponse un peu plus profonde que mon simple commentaire.
Il parlait de l'écart énorme entre le temps nécessaire pour livrer une fonctionnalité seul avec l'IA, et le temps nécessaire pour livrer la même fonctionnalité dans une grosse organisation.
Et sur le constat, je pense qu'il a raison.
Sur mes projets perso, je peux développer 2 ou 3 features en parallèle et les avoir fonctionnelles en prod en une heure.
Dans mon contexte professionnel actuel, chacune de ces features pourrait facilement prendre une journée, plusieurs jours, voire une semaine avant d'être développée, validée et livrée.
Mais ce n'est pas uniquement parce que les grosses boîtes sont lentes.
C'est aussi un calcul économique.
Quand votre web app a 1 à 100 utilisateurs quotidiens, casser la production n'est pas dramatique. Vous voyez le problème rapidement, vous corrigez, vous poussez un hotfix, parfois même en contournant la pipeline.
Le risque est faible. L'impact est limité. Et surtout : tout le contexte est dans votre tête.
Vous connaissez le code. Vous connaissez le produit. Vous connaissez les utilisateurs. Vous n'avez presque aucun compte à rendre en dehors d'eux.
Mais à partir d'un certain seuil, chaque seconde de production down coûte cher.
Des centaines. Des milliers. Parfois des millions.
Imaginez une minute d'indisponibilité chez Netflix, Google, League of Legends, Stripe ou AWS.
Ce sont des exemples extrêmes, évidemment. Mais dès qu'une application sert beaucoup d'utilisateurs, le coût d'une erreur change complètement.
La perte n'est pas seulement immédiate. Elle continue après l'incident.
Perte de confiance. Support client qui explose. Clients qui doutent. Équipes commerciales qui doivent rassurer au lieu de vendre. Obligations contractuelles potentielles. Image de marque abîmée. Abonnements annulés. Revenus coupés.
Donc les entreprises ajoutent des garde-fous.
Reviews. QA. Validation produit. Validation sécurité. Validation métier. Pipelines CI/CD. Processus de release. Rollback plans.
Et pour l'instant, malgré l'IA, une grande partie de cette vérification se doit de rester humaine.
Même les meilleurs utilisateurs d'IA font encore de la QA. Même les équipes les plus avancées vérifient que ce qui sort fonctionne vraiment.
Mais chaque validation a un coût.
Un reviewer ne fait pas juste “regarder le code”. Il doit reconstruire le contexte. Comprendre l'intention. Vérifier les impacts. S'assurer que la solution respecte les contraintes du projet.
Ajouter une personne dans la boucle ne multiplie donc pas simplement le temps par deux.
Ce n'est pas linéaire.
Plus il y a de personnes, plus il y a de coordination, d'explications, d'attente, de corrections, de revalidation.
Et ça apparaît à toutes les étapes :
- clarification de l'idée ;
- raffinement de la feature ;
- développement ;
- code review ;
- tests ;
- livraison.
C'est comme ça que des features finissent dans le purgatoire de la code review.
Et ce problème existait déjà avant l'IA.
L'IA accélère énormément la production de code. Mais elle ne supprime pas automatiquement le coût organisationnel autour du code.
Cela dit, ce n'est pas une excuse pour accepter la lenteur comme une fatalité.
Les grosses structures doivent faire mieux.
Décentraliser. Découper les applications. Réduire le blast radius. Automatiser ce qui peut l'être. Clarifier les responsabilités. Permettre des rollbacks simples. Donner plus d'autonomie aux équipes.
Parce que l'IA change quand même quelque chose de fondamental.
Elle permet à une petite équipe, ou même à une personne seule, d'attaquer des logiciels du quotidien qui étaient auparavant protégés par leur simple coût de développement.
Aujourd'hui, quand un outil me frustre, je me surprends à penser :
“En quelques semaines, je pourrais probablement développer ma propre version, adaptée à mon usage, et la proposer au monde.”
C'est assez incroyable.
Les grosses structures gardent encore un avantage énorme sur les infrastructures critiques, les systèmes à haute maintenance, la distribution, la confiance et les contraintes réglementaires.
Mais sur les outils du quotidien ? Sur les interfaces lentes, frustrantes, mal pensées ? Sur les workflows internes trop lourds ?
Le terrain devient beaucoup plus ouvert.
Il est temps de faire nos wrappers.
Lien vers son post : https://www.linkedin.com/posts/evan-boissonnot-coach-pour-cto-et-devs_un-dev-seul-avec-lia-livre-une-fonctionnalit%C3%A9-share-7478488942716203008-bCJ8/?utm_source=share&utm_medium=member_desktop&rcm=ACoAACByM6AB7Z6rh4NS9t75GZ1IaRGU6mnUT2U