# Nous n'avons jamais été sérieux qu'à moitié

**Résumé:** En 2015, nous avons publié un article sur la gestion d'une entreprise sur AWS sans aucun serveur, et utilisé cinquante pompes par user story comme métaphore de notre façon de travailler. Beaucoup de lecteurs l'ont pris pour une description de poste.

**En bref:** La métaphore remplissait une vraie fonction dans cet article, et elle a été reçue bien plus durement que nous ne l'imaginions

**Publié:** 2026-08-03

**Dernière mise à jour:** 2026-08-10

Le 7 décembre 2015, Marcel Panse et moi avons publié un article invité sur High Scalability intitulé [« The Serverless Start-up - Down With Servers! »](https://highscalability.com/the-serverless-start-up-down-with-servers/ "The Serverless Start-up - Down with Servers!"). Il expliquait comment nous avions construit Teletext.io sur API Gateway, Lambda, DynamoDB, S3 et CloudFront, sans aucun serveur à gérer. Pas un seul.

Quelque part au milieu, nous avions écrit ceci :

> We like rules. At our previous start-up Peecho, product owners had to do fifty push-ups as payment for each user story that they wanted to add to an ongoing sprint. Now, at our current company myTomorrows, our developer dance-offs are legendary: during the daily stand-ups, you are only allowed to speak while dancing - leading to the most efficient meetings ever.

Ce paragraphe est la raison pour laquelle on se souvient encore de cet article.

## Les deux étaient réels, pendant un temps

Les pompes ont vraiment eu lieu, et la danse aussi. Elles ont commencé comme des blagues internes, et nous les avons réellement pratiquées pendant un moment, ce qui est le sort de la plupart de nos règles : en inventer une, en profiter, en tirer quelque chose, puis la laisser discrètement s'éteindre. Personne ne gagnait encore ses tickets à coups de burpees au quatrième mois.

La danse mérite une explication, car le détail qui la faisait fonctionner est absent de l'article. Nous tenions le stand-up dans un grand espace ouvert, entouré du reste de l'entreprise. La règle ne portait donc pas vraiment sur la danse. Elle portait sur le fait de le faire devant tout le monde. Cela en faisait à la fois une blague organisationnelle et une limite de travail bien réelle.

Ce qu'elle n'a jamais été, c'est formalisée. Aucune politique, aucun manuel, rien à quoi qui que ce soit puisse être tenu - et c'était délibéré : à l'instant où vous écrivez que parler exige de danser, vous venez d'écrire une règle que tout le monde ne peut pas respecter. Cela nous paraissait évident à l'époque, et c'est exactement pour cela que la règle est restée informelle.

Dans l'article, pourtant, aucune des deux règles ne décrivait le quotidien. C'étaient des métaphores, et elles étaient là pour remplir une fonction.

## À quoi servait la métaphore

Nous voulions montrer comment nous aimons résoudre les problèmes : en fixant d'abord une limite stricte, puis en travaillant à l'intérieur, plutôt qu'en décidant au cas par cas. Une user story ajoutée en plein sprint a un coût réel. La traiter au cas par cas, et ce coût retombe discrètement sur l'équipe. Lui donner à la place un prix absurde et non négociable, en public, et soudain, chacun fait un choix délibéré.

Le sujet n'a jamais été les pompes, ni jamais la danse. C'était la limite, et le fait qu'on ne pouvait pas discrètement la contourner.

Et la blague n'a jamais vraiment été l'exercice non plus. La blague, c'était la prémisse : qu'une entreprise puisse exister où quelqu'un ferait réellement respecter cela, le plus sérieusement du monde, pour toujours. Nous nous moquions de notre propre sous-culture en jouant le jeu à fond, sans sourciller - une chose qu'on ne peut faire qu'à propos d'un monde dans lequel on se trouve soi-même. Écrire la raison sérieuse comme une blague nous a permis de faire valoir notre point tout en nous moquant de nous-mêmes dans le même souffle, et honnêtement, cela a fonctionné exactement comme prévu.

## Le même geste a construit l'architecture

C'est pourquoi ce paragraphe avait sa place dans cet article-là plutôt que dans un autre. Six paragraphes plus loin, nous avions écrit la version technique de cette même idée, à l'identique : chez Teletext.io, il nous était interdit d'utiliser des serveurs. Pas même un.

Ce n'est pas une conclusion à laquelle on arrive à partir d'un cahier des charges. C'est une règle arbitraire que nous nous sommes imposée, avant d'en concevoir la sortie. Notre propre formule dans l'article était que les contraintes nourrissent la créativité. Ne vous donnez aucun serveur, et vous trouverez API Gateway, Lambda et DynamoDB. Donnez à un product owner un tarif en pompes, et vous découvrirez quelles user stories comptaient vraiment.

La même méthode, deux fois, dans un seul article. Une version a eu droit à un diagramme d'architecture. L'autre a eu droit à une chute. Nous pensions que les lecteurs les verraient comme une paire assortie.

## Personne ne l'a lu ainsi

Il est arrivé en première page de r/programming et a fini à [142 votes positifs et 143 votes négatifs](https://www.reddit.com/r/programming/comments/3vwrf4/on_high_scalability_building_a_company_using_only/ "on High Scalability: Building a company using only..."), un partage à peu près aussi net que possible pour un fil de discussion.

Une partie du fil correspondait au débat que nous étions venus chercher, et c'était un bon débat. AWS Lambda n'avait été [annoncé en préversion qu'en novembre 2014](https://aws.amazon.com/about-aws/whats-new/2014/11/13/introducing-aws-lambda/ "Introducing AWS Lambda") et sortait à peine de sa disponibilité générale depuis quelques mois, si bien que les gens ont beaucoup insisté sur la dépendance au fournisseur, sur ce qui se passerait si Amazon augmentait ses prix, sur pourquoi DynamoDB plutôt qu'une instance Postgres sur RDS. Quelqu'un a lu le tableau de coûts mensuel comme s'il était quotidien, et a été poliment corrigé. Du contenu normal et utile.

En dessous se déroulait une conversation complètement différente, et l'indice était la façon dont on citait le paragraphe des pompes : en entier, sans rien ajouter d'autre que « Wtf? » et « What in the actual f***. »

Puis les questions ont commencé. « That part had me wondering if the whole article was satire. » « The dance-offs were satire, right? » « Is that serious, or satire? I'm having a bout of Poe's Law here. » Un commentateur débattait du volet technique depuis un moment, s'est arrêté en plein fil en réalisant que la citation était réelle, et a admis que la phrase avait été si ridicule qu'elle ne s'était pas imprimée à sa première lecture.

C'est à ce moment-là que tout est devenu clair. Quelques centaines d'ingénieurs avaient lu une métaphore comme une description de poste, et l'article ne parlait plus du tout de serverless.

Mon préféré venait de quelqu'un qui essayait de deviner où nous étions basés : « I assumed it was a Silicon Valley startup... turns out it is Amsterdam. It takes some effort to out-valley the valley. » Quelqu'un d'autre a écrit « Move over Mike Judge. » Quelqu'un a classé toute l'affaire sous r/programmingcirclejerk. En le relisant onze ans plus tard, j'ai ri tout aussi fort qu'à l'époque.

Ces trois-là se sont approchés plus que quiconque dans le fil. Ils avaient exactement le bon registre, avaient repéré l'énergie de sitcom façon Mike Judge, et avaient identifié que le paragraphe avait sa place dans un sub circlejerk. La seule chose qu'ils ont mal comprise, c'est le sens : ils ont supposé que nous étions le spécimen, plutôt que ceux qui en faisaient l'imitation.

## Le commentaire qui est arrivé à notre propre conclusion

Un commentaire m'est resté en mémoire, et ce n'était pas l'un des drôles.

Quelqu'un a écrit que c'était exactement le genre de détail qui donne lieu à des accusations d'âgisme. Quand une réponse lui a demandé ce qu'il voulait dire, il a expliqué : il s'imaginait son père de 65 ans en train de faire cinquante pompes pour pouvoir faire son travail, et sa mère, qui vivait avec une sclérose en plaques depuis la plus grande partie de sa vie, en train d'essayer de danser pour pouvoir parler lors d'un stand-up.

Il avait raison, et son raisonnement l'avait mené exactement là où le nôtre nous avait menés. C'est précisément pour cette raison qu'aucune des deux règles n'a jamais été écrite. Une blague dont on peut se désengager est une blague. Une exigence selon laquelle parler dépend d'un acte physique est autre chose, et cela exclut des gens dès l'instant où cela devient une politique.

La différence, c'est que nous le savions, et que lui ne pouvait pas le savoir. Nous avions présenté les règles dans l'article comme si c'étaient des règles, donc la seule lecture honnête à sa disposition était celle qu'il en a faite. Écrivez en métaphore, et vous ne choisissez pas qui la lira comme un fait - et les gens qui la lisent comme un fait ont parfaitement le droit de juger la chose qu'ils croient avoir devant eux. Son commentaire n'est pas une mauvaise lecture que je souhaite corriger. C'est la preuve la plus solide du fil que la blague n'aurait jamais dû devenir une politique - ce que nous avions déjà décidé.

## Personne n'avait encore de mot pour ça

Ce que nous avions produit par accident, c'était du rage bait. En 2015, ce n'était pas encore un genre. Personne n'écrivait de paragraphes pour cultiver l'indignation, le terme n'était pas d'usage courant, et ce n'était certainement pas une tactique que quiconque aurait admis employer.

Nous étions donc surtout perplexes, puis ravis. Nous avions écrit quelque chose pour que ce soit agréable à lire et pour dire quelque chose de vrai sur notre façon de travailler. Cela a plu, cela a dit la chose - et cela a aussi plongé une partie d'internet dans une fureur sincère à propos d'un lieu de travail qui avait cessé d'exister des mois plus tôt. Voir cela se produire en temps réel reste l'une des choses les plus drôles que nous ayons vécues, l'un comme l'autre.

## Ce qui s'est révélé vrai

Relisez aujourd'hui le volet technique, et il a une autre allure. Deux commentateurs ont fait des prédictions en plein débat. L'un a dit que les services de plateforme deviendraient la norme par défaut de toute façon, « much like high level programming languages have. » Un autre, défendant DynamoDB, a écrit qu'il serait difficile pour sa génération de bâtisseurs d'outils d'admettre qu'une solution clé en main pouvait suffire, et que « by 2020, they'll say no one was ever fired for choosing AWS. »

Les deux ont extrêmement bien vieilli. La position pour laquelle on se moquait de nous est aujourd'hui banale.

L'attention est devenue réelle aussi. Werner Vogels, alors CTO d'Amazon, a évoqué l'article et Teletext.io plus d'une fois, et [AWS nous a mis en avant dans sa série Hot Startups en août 2016](https://aws.amazon.com/blogs/aws/aws-hot-startups-august-2016/ "AWS Hot Startups - August 2016"). L'architecture a suffisamment bien tenu pour qu'UNLESS repose encore aujourd'hui sur cette base Teletext.io. Le déploiement commercial de Teletext.io est une autre histoire, que je raconterai une autre fois.

## Ce que je referais

Je garderais le paragraphe. Les lignes que la moitié du fil a balayées comme de la vanité étaient l'énoncé le plus clair de l'article sur la méthode qui avait produit la chose même dont ils débattaient. Choisissez une limite, laissez la contrainte faire le travail de conception, et vous arrivez quelque part où une discussion ouverte n'arriverait jamais. Nous construisons encore de cette façon, et c'est pourquoi Unless reste volontairement petit et ne fait qu'une seule chose.

Le fil m'a quand même appris où cette méthode trouve sa limite, et c'est une ligne plus nette que celle que j'aurais pu tracer à l'époque. On peut être absolu sur une contrainte imposée à un système. Aucun serveur, pas même un, est une règle qui ne coûte rien à une machine et qui force à réfléchir. On ne peut pas être absolu sur une contrainte imposée à des personnes, car dès l'instant où elle est écrite, quelqu'un en est exclu. C'est pourquoi l'une de ces règles figure encore dans le diagramme d'architecture onze ans plus tard, et l'autre n'est jamais sortie du statut de blague interne.

Ce que je n'avais pas compris en 2015, c'est à quel point la réaction avait peu à voir avec nous. Une salle pleine d'ingénieurs lisait depuis des années des articles sur la culture des start-up et en était profondément lassée, et nous leur avons tendu un spécimen frais au moment parfait. Ils ne débattaient pas vraiment de nos stand-ups. Ils débattaient d'une décennie de ces articles.

Le pari serverless n'a plus besoin d'être défendu. La métaphore, curieusement, reste la partie que je défendrais encore.