Pendant l'année 2014, Athoune m'a fait découvrir les concepts DevOps "Baking" et "Frying".

Je le remercie, car ce sont des concepts que je considère très importants pour comprendre les différents paradigmes de déploiement.

Je n'ai aucune idée dans quelles conditions il avait découvert ces concepts. J'ai essayé de faire des recherches limitées à l'année 2014 et je suis tombé sur cette photo :

J'en déduis que cela devait être un sujet à la méthode dans l'écosystème DevOps de 2014.

Cet ami me l'avait très bien expliqué avec une analogie du type :

« Le baking en DevOps, c’est comme dans un restaurant où les plats sont préparés en cuisine et ensuite apportés tout prêt salle à la table du client. Le frying, c’est comme si le plat était préparé directement en salle sur la table du client. »

Bien que cette analogie ne soit pas totalement rigoureuse, elle m'a bien permis de saisir, en 2014, le paradigme Docker qui consiste à préparer des images de container en amont. Ce paradigme permet d'installer, de configurer ces images "en cuisine", donc pas sur les serveurs de production, "de goûter les plats" et de les envoyer ensuite de manière prédictible sur le serveur de production.

Ces images peuvent être construites soit sur la workstation du développeur ou mieux, sur des serveurs dédiés à cette fonction, comme Gitlab-Runner…

Définitions proposées par LLaMa :

Baking (ou "Image Baking") : Il s'agit de créer une image de serveur prête à l'emploi, avec tous les logiciels et les configurations nécessaires déjà installés et configurés. Cette image est ensuite utilisée pour déployer de nouveaux serveurs, qui seront ainsi identiques et prêts à fonctionner immédiatement. L'avantage de cette approche est qu'elle permet de réduire le temps de déploiement et d'assurer la cohérence des environnements.

Frying (ou "Server Frying") : Il s'agit de déployer un serveur "nu" et de le configurer et de l'installer à la volée, en utilisant des outils d'automatisation tels que Ansible, Puppet ou Chef. Cette approche permet de personnaliser la configuration de chaque serveur en fonction des besoins spécifiques de l'application ou du service.

Exemple :

Cas d'usage	Baking	Frying
Docker	Construire une image complète (docker build) et la stocker dans un registre	Lancer un conteneur minimal et installer les dépendances au démarrage.
Machines virtuelles (VMs)	Créer une image VM avec Packer et la déployer telle quelle	Démarrer une VM de base et appliquer un script d’installation à la volée
CI/CD	Compiler et packager une application en image prête à être déployée	Construire l’application à chaque déploiement sur la machine cible

En 2014, lorsque le concept de baking m’a été présenté, j’ai immédiatement été enthousiasmé, car il répondait à trois problèmes que je cherchais à résoudre :

• Réduire les risques d’échec d’une installation sur le serveur de production
• Limiter la durée de l’indisponibilité (pendant la phase d’installation)
• Éviter d'augmenter la charge du serveur durant les opérations de build lors de l’installation

Depuis, j'évite au maximum le frying et j'ai intégré le baking dans ma doctrine d'artisan développeur.

Début novembre un ami me posait la question :

Quand tu déploies des conteneurs en prod, sans k8s, tu fais comment ?

Après 3 mois d'attente, voici ma réponse 🙂.

Mon contexte

Tout d'abord, un peu de contexte. Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Cela dit, j'ai également eu à gérer des infrastructures comportant plusieurs serveurs : 10, 20, 30 serveurs. Ces serveurs étaient généralement utilisés pour héberger une infrastructure de soutien (Platform infrastructure) à destination des développeurs. Par exemple :

• Environnements de recettage
• Serveurs pour faire tourner Gitlab-Runner
• Sauvegarde des données
• Etc.

Ce contexte montre que je n'ai jamais eu à gérer le déploiement de services à très forte charge, comme ceux que l'on trouve sur des plateformes telles que Deezer, le site des impôts, Radio France, Meetic, la Fnac, Cdiscount, France Travail, Blablacar, ou encore Doctolib. La méthode que je décris dans cette note ne concerne pas ce type d'infrastructure.

Ma méthode depuis 2015

Dans cette note, je ne vais pas retracer l'évolution complète de mes méthodes de déploiement, mais plutôt me concentrer sur deux d'entre elles : l'une que j'utilise depuis 2015, et une déclinaison adoptée en 2020.

Voici les principes que j'essaie de suivre et qui constituent le socle de ma doctrine en matière de déploiement de services :

• Je m'efforce de suivre le modèle Baking autant que possible (voir ma note 2025-02-07_1403), sans en faire une approche dogmatique ou extrémiste.
• J'applique les principes de The Twelve-Factors App.
• Je privilégie le paradigme Remote Task Execution, ce qui me permet d'adopter une approche GitOps.
• J'utilise des outils d'orchestration prenant en charge le mode push (voir note 2025-02-07_1612), comme Ansible, et j'évite le mode pull.

En pratique, j'utilise Ansible pour déployer un fichier docker-compose.yml sur le serveur de production et ensuite lancer les services.

Je précise que cette note ne traite pas de la préparation préalable du serveur, de l'installation de Docker, ni d'autres aspects similaires. Afin de ne pas alourdir davantage cette note, je n'aborde pas non plus les questions de Continuous Integration ou de Continuous Delivery.

Imaginons que je souhaite déployer le lecteur RSS Miniflux connecté à un serveur PostgreSQL.
Voici les opérations effectuées par le rôle Ansible à distance sur le serveur de production :

• 1. Création d'un dossier /srv/miniflux/
• 2. Upload de /srv/miniflux/docker-compose.yml avec le contenu suivant :

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: password
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:password@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: secret
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

• 3. Depuis le dossier /srv/miniflux/ lancement de la commande docker compose up -d --remove-orphans --wait --pull always

Voilà, c'est tout 🙂.

En 2020, j'enlève "une couche"

J'aime enlever des couches et en 2020, je me suis demandé si je pouvais pratiquer avec élégance la méthode Remote Execution sans Ansible.
Mon objectif était d'utiliser seulement ssh et un soupçon de Bash.

Voici le résultat de mes expérimentations.

J'ai besoin de deux fichiers.

• _payload_deploy_miniflux.sh
• deploy_miniflux.sh

Voici le contenu de _payload_deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

PROJECT_FOLDER="/srv/miniflux/"

mkdir -p ${PROJECT_FOLDER}

cat <<EOF > ${PROJECT_FOLDER}docker-compose.yaml
services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_DB: miniflux
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: {{ .Env.MINIFLUX_POSTGRES_PASSWORD }}
    volumes:
      - postgres:/var/lib/postgresql/data/
    healthcheck:
      test: ['CMD', 'pg_isready']
      interval: 10s
      start_period: 30s

  miniflux:
    image: miniflux/miniflux:2.2.5
    ports:
    - 8080:8080
    environment:
      DATABASE_URL: postgres://miniflux:{{ .Env.MINIFLUX_POSTGRES_PASSWORD }}@postgres/miniflux?sslmode=disable
      RUN_MIGRATIONS: 1
      CREATE_ADMIN: 1
      ADMIN_USERNAME: johndoe
      ADMIN_PASSWORD: {{ .Env.MINIFLUX_ADMIN_PASSWORD }}
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  postgres:
     name: miniflux_postgres

EOF

cd ${PROJECT_FOLDER}

docker compose pull
docker compose up -d --remove-orphans --wait

Voici le contenu de deploy_miniflux.sh :

#!/usr/bin/env bash
set -e

cd "$(dirname "$0")/../"

gomplate -f _payload_deploy_miniflux.sh | ssh root@$SERVER1_IP 'bash -s'

J'utilise gomplate pour remplacer dynamiquement les secrets dans le script _payload_deploy_miniflux.sh.

En conclusion, pour déployer une nouvelle version, j'ai juste à exécuter :

$ ./deploy_miniflux.sh

Je trouve cela minimaliste et de plus, l'exécution est bien plus rapide que la solution Ansible.

Ce type de script peut ensuite être exécuté aussi bien manuellement par un développeur depuis sa workstation, que via GitLab-CI ou même Rundeck.

Pour un exemple plus détaillé, consultez ce repository : https://github.com/stephane-klein/poc-bash-ssh-docker-deployement-example

---

Bien entendu, si vous souhaitez déployer votre propre application que vous développez, vous devez ajouter à cela la partie baking, c'est-à-dire, le docker build qui prépare votre image, l'uploader sur un Docker registry… Généralement je réalise cela avec GitLab-CI/CD ou GitHub Actions.

---

Objections

Certains DevOps me disent :

• « Mais on ne fait pas ça pour de la production ! Il faut utiliser Kubernetes ! »
• « Comment ! Tu n'utilises pas Kubernetes ? »

Et d'autres :

• « Il ne faut au grand jamais utiliser docker-compose en production ! »

Ne jamais utiliser docker compose en production ?

J'ai reçu cette objection en 2018. J'ai essayé de comprendre les raisons qui justifiaient que ce développeur considère l'usage de docker compose en production comme un Antipattern.

Si mes souvenirs sont bons, je me souviens que pour lui, la bonne méthode conscistait à déclarer les états des containers à déployer avec le module Ansible docker_container (le lien est vers la version de 2018, depuis ce module s'est grandement amélioré).

Je n'ai pas eu plus d'explications 🙁.

J'ai essayé d'imaginer ses motivations.

J'en ai trouvé une que je ne trouve pas très pertinente :

• Uplodaer un fichier docker-compose.yml en production pour ensuite lancer des fonctions distantes sur celui-ci est moins performant que manipuler docker-engine à distance.

J'en ai imaginé une valable :

• En déclarant la configuration de services Docker uniquement dans le rôle Ansible cela garantit qu'aucun développeur n'ira modifier et manipuler directement le fichier docker-compose.yml sur le serveur de production.

Je trouve que c'est un très bon argument 👍️.

Cependant, cette méthode a à mes yeux les inconvénients suivants :

• Je maitrise bien mieux la syntaxe de docker compose que la syntaxe du module Ansible community.docker.docker_container
• J'utilise docker compose au quotidien sur ma workstation et je n'ai pas envie d'apprendre une syntaxe supplémentaire uniquement pour le déploiement.
• Je pense que le nombre de développeurs qui maîtrisent docker compose est suppérieur au nombre de ceux qui maîtrisent le module Ansible community.docker.docker_container.
• Je ne suis pas utilisateur maximaliste de la méthode Remote Execution. Dans certaines circonstances, je trouve très pratique de pouvoir manipuler docker compose dans une session ssh directement sur un serveur. En période de stress ou de debug compliqué, je trouve cela pratique. J'essaie d'être assez rigoureux pour ne pas oublier de reporter mes changements effectués directement le serveur dans les scripts de déploiements (configuration as code).

Tu dois utiliser Kubernetes !

Alors oui, il y a une multitude de raisons valables d'utiliser Kubernetes. C'est une technologie très puissante, je n'ai pas le moindre doute à ce sujet.
J'ai une expérience dans ce domaine, ayant utilisé Kubernetes presque quotidiennement dans un cadre professionnel de janvier 2016 à septembre 2017. J'ai administré un petit cluster auto-managé composé de quelques nœuds et y ai déployé diverses applications.

Ceci étant dit, je rappelle mon contexte :

Cela fait 25 ans que je travaille sur des projets web, et tous les projets sur lesquels j'ai travaillé pouvaient être hébergés sur un seul et unique serveur baremetal ou une Virtual machine, sans jamais nécessiter de scalabilité horizontale.

Je n'ai jamais eu besoin de serveurs avec plus de 96Go de RAM pour faire tourner un service en production. Il convient de noter que, dans 80% des cas, 8 Go ou 16 Go étaient largement suffisants.

Je pense que faire appel à Kubernetes dans ce contexte est de l'overengineering.

Je dois avouer que j'envisage d'expérimenter un usage minimaliste de K3s (attention au "3", je n'ai pas écrit k8s) pour mes déploiements. Mais je sais que Kubernetes est un rabbit hole : Helm, Kustomize, Istio, Helmfile, Grafana Tanka… J'ai peur de tomber dans un Yak!.

D'autre part, il existe déjà un pourcentage non négligeable de développeur qui ne maitrise ni Docker, ni docker compose et dans ces conditions, faire le choix de Kubernetes augmenterait encore plus la barrière à l'entrée permettant à des collègues de pouvoir comprendre et intervenir sur les serveurs d'hébergement.

C'est pour cela que ma doctrine d'artisan développeur consiste à utiliser Kubernetes seulement à partir du moment où je rencontre des besoins de forte charge, de scalabilité.

Alexandre me dit : « Le contenu de Speed of Code Reviews (https://google.github.io/eng-practices/review/reviewer/speed.html) ressemble à ce dont tu faisais la promotion dans notre précédente équipe ».

En effet, après lecture, les recommandations de cette documentation font partie de ma doctrine d'artisan développeur.

Note: j'ai remplacé CL qui signifie Changelist par Merge Request.

When code reviews are slow, several things happen:

• The velocity of the team as a whole is decreased. Yes, the individual who doesn’t respond quickly to the review gets other work done. However, new features and bug fixes for the rest of the team are delayed by days, weeks, or months as each Merge Request waits for review and re-review.
• Developers start to protest the code review process. If a reviewer only responds every few days, but requests major changes to the Merge Request each time, that can be frustrating and difficult for developers. Often, this is expressed as complaints about how “strict” the reviewer is being. If the reviewer requests the same substantial changes (changes which really do improve code health), but responds quickly every time the developer makes an update, the complaints tend to disappear. Most complaints about the code review process are actually resolved by making the process faster.
• Code health can be impacted. When reviews are slow, there is increased pressure to allow developers to submit Merge Request that are not as good as they could be. Slow reviews also discourage code cleanups, refactorings, and further improvements to existing Merge Request.

source

J'ai fait le même constat et je trouve que cette section explique très bien les conséquences 👍️.

How Fast Should Code Reviews Be?

If you are not in the middle of a focused task, you should do a code review shortly after it comes in.

One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).

Following these guidelines means that a typical Merge Request should get multiple rounds of review (if needed) within a single day.

source

Je partage et recommande cette pratique 👍️.

If you are too busy to do a full review on a Merge Request when it comes in, you can still send a quick response that lets the developer know when you will get to it, suggest other reviewers who might be able to respond more quickly.

source

👍️

Large Merge Request

If somebody sends you a code review that is so large you’re not sure when you will be able to have time to review it, your typical response should be to ask the developer to split the Merge Request into several smaller Merge Requests that build on each other, instead of one huge Merge Request that has to be reviewed all at once. This is usually possible and very helpful to reviewers, even if it takes additional work from the developer.

source

Je partage très fortement cette recommandation et je pense que c'est celle que j'avais le plus de difficulté à faire accepter par les nouveaux développeurs.

Quand je code, j'essaie de garder à l'esprit que mon objectif est de faciliter au maximum le travail du reviewer plutôt que de chercher à minimiser mes propres efforts.

J'ai sans doute acquis cet état d'esprit du monde open source. En effet, l'un des principaux défis lors d'une contribution à un projet open source est de faire accepter son patch par le mainteneur. On comprend rapidement qu'un patch doit être simple à comprendre et rapide à intégrer pour maximiser ses chances d'acceptation.

Un bon patch doit remplir un objectif unique et ne contenir que les modifications strictement nécessaires pour l'atteindre.

Je suis convaincu que si une équipe de développeurs applique ces principes issus de l'open source dans leur contexte professionnel, leur efficacité collective s'en trouvera grandement améliorée.

Par ailleurs, une Merge Request de taille réduite présente plusieurs avantages concrets :

• elle est non seulement plus simple à rebase,
• mais elle a aussi plus de chances d'être mergée rapidement.

Cela permet à l'équipe de bénéficier plus rapidement des améliorations apportées, qu'il s'agisse de corrections de bugs ou de nouvelles fonctionnalités.

Dans cette note, je souhaite présenter ma doctrine de mise à jour d'OS de serveurs.

Je ne traiterai pas ici de la stratégie d'upgrade pour un Cluster Kubernetes.

La mise à jour d'un serveur, par exemple, sous un OS Ubuntu LTS, peut être effectuée avec les commandes suivantes :

• sudo apt upgrade -y
• ou sudo apt dist-upgrade -y (plus risqué)
• ou sudo do-release-upgrade (encore plus risqué)

L'exécution d'un sudo apt upgrade -y peut :

• Installer une mise à jour de docker, entraînant une interruption des services sur ce serveur de quelques secondes à quelques minutes.
• Installer une mise à jour de sécurité du kernel, nécessitant alors un redémarrage du serveur, ce qui entraînera une coupure de quelques minutes.

Une montée de version de l'OS via sudo do-release-upgrade peut prendre encore plus de temps et impliquer des ajustements supplémentaires.

Bien que ces opérations se déroulent généralement sans encombre, il n'y a jamais de certitude totale, comme l'illustre l'exemple de la Panne informatique mondiale de juillet 2024.

Sachant cela, avant d'effectuer la mise à jour d'un serveur, j'essaie de déterminer quelles seraient les conséquences d'une coupure d'une journée de ce serveur.

Si je considère que ce risque de coupure est inacceptable ou ne serait pas accepté, j'applique alors la méthode suivante pour réaliser mon upgrade.

Je n'effectue pas la mise à jour le serveur existant. À la place, je déploie un nouveau serveur en utilisant mes scripts automatisés d'Infrastructure as code / GitOps.

C'est pourquoi je préfère éviter de nommer les serveurs d'après le service spécifique qu'ils hébergent (voir aussi Pets vs Cattle). Par exemple, au lieu de nommer un serveur gitlab.servers.example.com, je vais le nommer server1.servers.example.com et configurer gitlab.servers.example.com pour pointer vers server1.servers.example.com.

Ainsi, en cas de mise à jour de server1.servers.example.com, je crée un nouveau serveur nommé server(n+1).servers.example.com.

Ensuite, je lance les scripts de déploiement des services qui étaient présents sur server1.servers.example.com.

Idéalement, j'utilise mes scripts de restauration des données depuis les sauvegardes des services de server1.servers.example.com, ce qui me permet de vérifier leur bon fonctionnement. Ensuite, je prépare des scripts rsync pour synchroniser rapidement les volumes entre server1.servers.example.com et server(n+1).servers.example.com.

Je teste que tout fonctionne bien sur server(n+1).servers.example.com.

Si tout fonctionne correctement, alors :

• J'arrête les services sur server(n+1).servers.example.com ;
• J'exécute le script de synchronisation rsync de server1.servers.example.com vers server(n+1).servers.example.com ;
• Je relance les services sur server(n+1).servers.example.com
• Je modifie la configuration DNS pour faire pointer les services de server1.servers.example.com vers server(n+1).servers.example.com
• Quelques jours après cette intervention, je décommissionne server1.servers.example.com.

Cette méthode est plus longue et plus complexe qu'une mise à jour directe de l'OS sur le server1.servers.example.com, mais elle présente plusieurs avantages :

• Une grande sécurité ;
• L'opération peut être faite tranquillement, sans stress, avec de la qualité ;
• Une durée de coupure limitée et maîtrisée ;
• La possibilité de confier la tâche en toute sécurité à un nouveau DevOps ;
• La garantie du bon fonctionnement des scripts de déploiement automatisé ;
• La vérification de l'efficacité des scripts de restauration des sauvegardes ;
• Un test concret des scripts et de la documentation du Plan de reprise d'activité.

Si le serveur à mettre à jour fonctionne sur une Virtual instance, il est également possible de cloner la VM et de tester la mise à niveau. Cependant, je préfère éviter cette méthode, car elle ne permet pas de valider l'efficacité des scripts de déploiement.

#JaiLu

Rich Harris explains this clearly. JSDoc for writing a lib. TypeScript for writing an app. (from)

Ce conseil entre en opposition avec ce que j'ai écrit en octobre 2023 :

Si je dois coder et publier une librairie sur npm alors, je choisis TypeScript.
Quand je dis librairie, je parle de librairie qui contient des classes, des fonctions ou des composants importés par d'autres projets.

Pourquoi est-ce que je choisis d'utiliser TypeScript pour les librairies ?

• Je permets aux développeurs qui utilisent TypeScript dans leur projet, de pouvoir bénéficier de la documentation, l'autocomplétion, la détection des erreurs… de la librairie que j'aurais mise à disposition ;
• Je n'ai pas vérifié, mais je pense que le typage de TypeScript permet à des outils d'auto générer une grande partie de la documentation d'une librairie.

Ce conseil entre aussi en opposition avec ce second élément que j'ai écrit en octobre 2023 :

Si je dois coder une application web, alors pour le moment, je choisis JavaScript.
Le code implémenté dans une application web, n'est généralement pas utilisé par des utilisateurs "externes". Par conséquent, je ne trouve pas très important de mettre à disposition une documentation aux autres développeurs. Je pense qu'à petite taille, l'effort ne vaut pas la peine. Ma réponse est peut-être différente si 10, 20… développeurs contribuent à la même base code 🤔.

• Généralement, le code d'une application web est plutôt simple, beaucoup de CRUD et peu de librairie complexe.
• Pour le moment, je pense que l'effort d'ajouter le boilerplate code de typage TypeScript (importer les types, d'ajouter le typage dans le code) ne sera pas compensé par les fonctionnalités de détection d'erreurs , d'autocomplétions et de refactoring que permet TypeScript.

Je pense qu'il serait bon que je revoie ma doctrine d'artisan développeur sur ce sujet.

Cela fait depuis décembre 2023 que je souhaite traduire l'article The Platinum Rule de Shawn Wang (dit swyx), c'est chose faite :

Voici la Traduction de "The Platinum Rule" 🙂.

Pourquoi avoir traduit cet article ?
Parce que quand je l'ai lu, il m'a fait beaucoup réfléchir parce que j'ai réalisé que j'ai été depuis tout petit très conditionné par la règle d'or. J'essayais au maximum de la respecter et j'imaginais que si tout le monde la respectait, tout irait pour le mieux… mais avant de lire cet article, c'est bête à dire, mais je n'avais pas réalisé qu'en pratique, cela ne fonctionnait pas.

En lisant cet article, je pense qu'il est bon de garder à l'esprit que Shawn Wang (dit swyx) est un développeur et je pense qu'il a écrit cet article en rapport à des difficultés de travailler en équipe sur des projets de développement.

Pensez, par exemple, aux conventions de coding style et à bien d'autre sujets !

N'hésitez pas à venir échanger avec moi pour me partager votre avis sur le sujet, cela m'intéresse 🙂.

#JaiLu l'article Don’t Build A General Purpose API To Power Your Own Front End.

TL;DR YAGNI, unless you’re working in a big company with federated front-ends or GraphQL.

It’s popular in web dev nowadays to build a backend that serves JSON, and a frontend that renders the app. This is fine. I’m not the biggest fan, but it’s really okay. Except it’s not okay if you think that your backend needs to be designed like a generic public API. This will not save you time.

Je partage à 100% cette opinion.

Ma traduction de l'article The Platinum Rule de Shawn Wang (dit swyx) avec quelques modifications et ajouts qui me permettent — peux-être à vous aussi — de mieux comprendre l'article.

La traduction commence ici ⬇️

---

Vous avez entendu parler de la la règle d'or : « Traiter les autres comme on voudrait être traité » ou « Ne fais pas aux autres ce que tu ne voudrais pas qu'on te fasse ».

Je pense qu'elle est incomplète. Je pense que les gens fonctionnent en réalité selon une norme plus élevée. Je propose la Règle de Platine : Traiter les autres comme ILS veulent être traités.

La Règle de Platine

Pour comprendre comment j'en suis arrivé là, il faut savoir que j'ai des traits de personnalité particuliers qui rendent la règle de Platine pertinente pour moi. Je préfère la franchise. Mon seuil pour considérer quelque chose comme "terminé" est plus bas que le vôtre. J'aime les personnes conscientes d'elles-mêmes et l'humour. Je préfère l'amour vache.

Cela signifie que je préfère livrer une chose imparfaite et itérer plutôt que de mettre de l'ordre dans mes affaires. Cela signifie que je dis les choses sans les adoucir pour les rendre plus agréables à entendre. Cela signifie que je me moque de moi-même et de tout ce à quoi je m'identifie fortement, ce qui peut parfois inclure les personnes avec lesquelles je travaille. Cela signifie que je suis souvent trop dur à l'égard de quelque chose qui me tient à cœur.

En lisant ce paragraphe — ci-dessus — certains d'entre vous ont sans doute pensée « ok, et alors ? » sans voir ce qu'il ne va pas dans ce comportement. Voici ce qui ne va pas.

Pourquoi la règle d'or pose problème ?

Imaginons que nous simplifions les préférences humaines en deux catégories : « plus particulières » et « moins particulières ».
Et supposons que les interactions humaines se résument à deux aspects : « comment vous traitez les autres » et « comment vous voulez être traité ».
La règle d'or — traiter les autres comme vous voulez être traité — suggère que les personnes plus particulières devraient traiter les autres selon leurs propres standards élevés — peu importe comment vous définissez ces standards.
C'est une bonne chose car cela rend les personnes particulières très prévenantes. Cependant, si les personnes moins particulières appliquaient cette règle et traitaient les autres comme elles veulent être traitées, elles paraîtraient vraiment désagréables aux yeux des personnes plus particulières, qui ne pourraient pas travailler avec elles.

Par exemple, imaginez quelqu'un qui aime que tout soit toujours bien rangé et organisé. Cette personne, très particulière sur la propreté, pourrait être très attentive à maintenir un environnement propre et ordonné pour tout le monde.
Cependant, si une personne qui ne se soucie pas autant du rangement appliquait la règle d'or et traitait les autres comme elle veut être traitée (c'est-à-dire sans se soucier de l'ordre), elle semblerait désordonnée et négligente aux yeux de la personne qui apprécie l'ordre. Cela créerait des tensions, car la personne qui aime l'ordre se sentirait frustrée et incapable de travailler efficacement avec l'autre.

Dans cet exemple, la règle d'or ne fonctionne pas bien, la personne qui aime l'ordre traite l'autre comme elle aimerait être traité, mais son souhaite ne se réalise pas !

Les nombres relatifs de personnes plus particulières et de personnes moins particulières n'ont pas d'importance - si ces personnes doivent travailler ensemble, elles doivent coexister dans le cadre d'un contrat social différent.

La règle de platine ?

Pour essayer de résoudre ce problème, je propose que la règle de platine soit ce contrat : traiter les autres comme ils veulent être traités.

D'un côté, cela semble relever de la plus simple politesse : bien sûr, il faut tenir compte des sentiments des autres. Utilisez leurs pronoms. Respecter leur autonomie et leur liberté.

D'un autre côté, cela peut sembler beaucoup trop accommodant - que faire si les gens abusent du système et veulent être traités de manière déraisonnable ? Il y a deux poids, deux mesures partout lorsqu'il s'agit d'intérêt personnel. Il faut bien tracer une ligne quelque part.

Elle est imparfaite, mais il est probable que le bon équilibre entre vous et moi se situe quelque part entre la Règle d'Or (empathie extrêmement centrée sur soi) et la Règle de Platine (accommodement extrêmement centré sur les autres).

---

La Règle d'Argent

En réfléchissant à cela dans un avion, j'ai également pensé à une belle conclusion pour ce message. Si la règle de platine est "meilleure" que la règle d'or, à quoi ressemblerait une règle d'argent ? (j'aime étendre les idées comme celle-ci, j'ai pris cela de Brian Chesky).

Une règle d'argent serait quelque chose qui est souvent considéré comme secondaire par rapport aux autres, mais qui reste important et précieux. Et sous la forme suivante : « Traitez x comme X veut être traité ».

Voici ma proposition pour une règle d'argent : Traitez-vous comme vous traitez les autres. Une belle inversion de la règle d'or.

Le framework des quatre tendances de Gretchen Rubin divise les gens en fonction de la façon dont ils répondent aux attentes intérieures et extérieures, ce qui semble tout à fait approprié à ce sujet. Les profils "Questioners" ont le plus besoin de la Règle de Platine. Mais les "Obligers" ont probablement le plus besoin de la Règle d'Argent.

Le souci de soi ne doit pas céder la place au sacrifice de soi.