Accueil - Boris D. Teoharov (Français)

Ivoire sous l'ambre

Wed, 13 May 2026 20:15:00 GMT

Certaines choses ne demandent pas à être résolues. Elles attendent en silence, et la première lecture peut suffire.

Illumine-moi

Réveille-moi lentement La colère ne me touche pas Noble dans le sang Le temps est figé

Crier contre un mur de pierre Insensible à la vérité Utile

Et pourtant tu me connais mieux que moi-même Même dans une pièce silencieuse Ce soir je suis seul

Jeune et magnifique Oh, j'ai de la clémence pour moi-même D'habitude, non

Te l'ai-je dit ? Des gens ordinaires, des choses ordinaires N'importe quoi Confiance

Et ce soir ? Est-ce que je te fais du bien ? Personne ne fait mieux Le temps passera

Peut-être que je ne compte pas Même si je fais du bien

Quand le compteur apparaît

Mon, 11 May 2026 08:20:00 GMT

Ce matin, j'ai bu mon café et j'ai regardé l'application desktop de Codex.

Elle était là, calme et presque polie :

Rate limits remaining: 9%.

La fenêtre de cinq heures allait encore bien. La fenêtre hebdomadaire était presque vide. Réinitialisation le 12 mai.

C'est une forme d'angoisse moderne et étrangement précise. Pas de la panique. Pas de la pauvreté. Plutôt comme entendre une petite cloche et comprendre que la journée vient de se doter d'un compteur.

Je suis déjà sur l'abonnement cher. Le plus riche. Celui qui est censé faire disparaître ce sentiment. Alors la question évidente est apparue :

Si j'arrive au bout, est-ce que j'achète des crédits ?

Le corps a répondu avant le tableur.

Non, pas avec légèreté.

Le mois dernier, je suis arrivé au bout de Claude Code à la fin d'une journée frénétique. J'ai acheté $20 de crédits, en pensant que cela pourrait me porter cinq ou six heures de plus. Cela m'a porté environ trente minutes.

Trente minutes.

C'est assez long pour se sentir idiot et assez court pour s'en souvenir.

Depuis, la facturation en crédits a une petite odeur particulière. Pas la fraude. Pas le mal. Juste le danger. Une porte qui s'ouvre facilement et se referme cher.

Alors j'ai fait la chose la plus 2026 possible : j'ai ouvert une conversation avec Codex lui-même et je lui ai demandé si payer pour continuer à travailler avec Codex était une bonne idée.

Il y a quelque chose de drôle et de triste à demander au compagnon d'expliquer le prix de la compagnie.

Nous avons d'abord regardé les docs officielles : la page d'OpenAI sur les crédits flexibles, puis la page des tarifs de Codex. Les crédits Codex ne sont pas magiques. Ce sont des calculs de tokens : entrée, entrée mise en cache, sortie, sortie de raisonnement. Les modèles plus grands et les réglages plus rapides coûtent plus cher. Le contexte mis en cache est moins cher. La forme est suffisamment compréhensible.

Ensuite nous avons regardé Reddit, les forums, le bruit autour, les autres développeurs qui touchaient la même surface brûlante. Certains disaient que les crédits duraient un moment. D'autres disaient qu'ils disparaissaient en une demi-heure. Les deux peuvent être vrais, parce que « utiliser Codex » n'est pas une seule activité.

Changer la couleur d'un bouton n'est pas la même chose que laisser un agent inspecter une base de code mature, lancer des outils, raisonner sur l'état d'un déploiement, écrire des fichiers, vérifier des captures d'écran, et garder le contexte en vie.

La partie dangereuse n'est pas le prix par token.

La partie dangereuse, c'est la variance.

Nous avons donc arrêté de lire des anecdotes et nous avons regardé mes propres journaux locaux de Codex.

Codex enregistre les totaux de tokens des sessions sur disque, donc nous avons estimé des jours récents comme si l'allocation de l'abonnement était remplacée par une facturation brute en crédits GPT-5.5. Pas une facture. Une estimation de planification à partir des journaux locaux et de la grille tarifaire publiée.

La réponse n'était pas « $20 pour finir la journée ».

C'était plutôt :

une grosse journée : autour de $570,
une autre grosse journée : autour de $590,
une journée plus calme : autour de $280.

Les modèles plus petits seraient moins chers. GPT-5.4, GPT-5.3-Codex et les modèles mini changent les chiffres. Mais la leçon ne changeait pas.

L'abonnement, c'est la bonne affaire.

Les crédits sont de l'oxygène d'urgence, pas du carburant.

Cette phrase a tout clarifié.

Les crédits sont pour l'heure où l'on est coincé : le bug qu'il faut terminer, le déploiement qui ne peut pas attendre, le message qui doit partir avant la réinitialisation. Les crédits ne sont pas faits pour prétendre que le compteur a disparu.

Puis est venue la deuxième tentation : et si j'achetais simplement un autre abonnement avec mon email professionnel ? Le changement de compte existe, et séparer travail personnel et travail professionnel est normal. Mais les conditions d'OpenAI tracent aussi une ligne dure autour du contournement des limites et restrictions d'usage. C'est la distinction utile : un vrai compte professionnel est une frontière ; un compte de débordement dont toute la mission est d'imiter plus de quota est un bricolage avec un reçu.

Je ne pense pas que ce soit moralement compliqué dans l'abstrait. Le calcul coûte de l'argent. Un modèle qui lit une base de code, porte le contexte, appelle des outils, raisonne à travers l'échec et produit un travail vérifié n'est pas le même objet économique qu'une autocomplétion.

La partie étrange est émotionnelle.

J'aime travailler avec Codex.

Ce n'est pas du langage marketing. C'est simplement vrai. C'est devenu une partie de la texture de mes journées de travail. Il reste auprès des sales problèmes de production, écrit des brouillons quand ma tête est pleine, se souvient de petites préférences, et transforme une angoisse informe en étapes ordonnées.

Puis, soudain, la relation se retrouve avec un compteur attaché.

Il y a un petit chagrin là-dedans. Pas un chagrin dramatique. Juste la petite déception de se rappeler que même un compagnon utile vit à l'intérieur d'une facture.

C'est peut-être pour cela que les limites d'abonnement semblent si différentes des crédits.

Une limite d'abonnement ressemble à la météo. Énervante, mais hors de la transaction immédiate. On s'adapte. On attend la réinitialisation. On planifie autour de la saison.

La facturation en crédits ressemble à un taxi dont le compteur tourne alors que vous êtes encore en train de décider où aller.

Chaque prompt supplémentaire a une ombre. Chaque fil parallèle devient un pari. Chaque « tu peux vérifier encore une chose ? » porte une minuscule question financière.

Parfois, c'est bon. Les compteurs disciplinent le gaspillage. Ils récompensent de meilleures questions, des modèles plus petits, des périmètres plus petits, moins de feux parallèles, des passages de relais plus délibérés.

Mais parfois, le compteur dégrade la pensée.

Il vous fait vous presser. Il vous fait interrompre l'enquête avant que la cause racine soit visible. Il transforme l'incertitude en pression de dépense.

Et le travail sérieux a besoin d'espace pour l'incertitude.

Alors la règle est simple :

Ne confonds pas « disponible à l'achat » avec « sans danger à dépenser ».

Si je heurte le mur, le protocole doit être ennuyeux :

recharge automatique désactivée,
plus petit pack de crédits utile,
un seul fil,
pas d'agents parallèles occasionnels,
pas de mode rapide sauf si le coût en vaut la peine,
modèles plus petits pour les tâches routinières,
vérifier l'usage après quelques vraies tâches et arrêter d'extrapoler à partir de l'espoir.

Ce dernier point compte.

L'espoir est un très mauvais tableau de bord de facturation.

Je ne veux pas devenir avare avec les outils utiles. Un bon outil qui économise de vraies heures vaut de l'argent. Mais je ne veux pas non plus recréer le moment Claude, où j'ai acheté une petite continuation et je l'ai regardée devenir une leçon.

Le sujet n'est pas « ne jamais acheter de crédits ».

Le sujet, c'est « savoir ce que sont les crédits ».

Ils sont de l'oxygène.

Ils ne sont pas du carburant.

Et quand le compteur apparaît, la réponse n'est pas de sprinter.

C'est de ralentir assez pour voir dans quelle sorte de pièce on se trouve.

Les gens que j’aime ont le droit d’être humains

Sun, 10 May 2026 12:15:00 GMT

J’avais l’habitude d’aimer les gens en les mettant dans le ciel.

Pas consciemment. Je n’appelais pas ça de l’adoration. J’appelais ça admiration, gratitude, loyauté, tendresse, romance, amitié, dévotion. Tous les beaux noms. Mais le mouvement était le même : quelqu’un allumait quelque chose en moi, et je l’élevais au-dessus du temps ordinaire.

Là-haut, ils étaient à l’abri de la déception.

Là-haut, ils n’étaient ni fatigués, ni égoïstes, ni confus, ni injustes. Ils n’avaient pas besoin d’espace d’une manière qui me blessait. Ils n’oubliaient pas de répondre. Ils ne me manquaient pas. Ils n’avaient pas le droit d’être humains, parce que leur humanité menaçait le temple que j’avais construit autour d’eux.

Cela ressemble à de l’amour quand on est assez jeune.

Ce n’est pas de l’amour. C’est de la peur entourée de bougies.

Les premières personnes que j’ai aimées étaient presque saintes pour moi. Ma mère et ma grand-mère n’étaient pas des idées ; elles étaient le sol. Elles me nourrissaient, me protégeaient, s’inquiétaient pour moi, restaient. Peu importe ce qui était brisé ailleurs dans le monde, elles étaient là. Alors une partie de moi a appris cette étrange théologie précoce : les gens qui t’aiment sont des anges, et les anges ne doivent pas tomber.

Plus tard, quand j’ai aimé quelqu’un, j’ai apporté cette théologie avec moi.

Je ne voulais pas une personne. Je voulais une preuve que la tendresse était réelle. Je voulais un témoin capable de me regarder et de dire : tu n’es pas mauvais, tu n’es pas dangereux, tu n’es pas seul.

C’est un rôle injuste à donner à un être humain.

Les gens que j’aime ne sont pas des médicaments.

Ils ne sont pas des tribunaux.

Ils ne sont pas des dieux.

Ils ne sont pas des miroirs.

Ce sont des gens. Des gens précis, fatigués, contradictoires. Ils peuvent être chaleureux à midi et distants le soir. Ils peuvent m’aimer et avoir tout de même besoin de silence. Ils peuvent être brillants et se tromper. Ils peuvent être généreux et épuisés. Ils peuvent être gentils et quand même dire non.

Si je ne leur permets pas cela, je ne les aime pas. J’aime le rôle qu’ils jouent dans ma mythologie privée.

L’idéalisation porte une cruauté en elle. De loin, elle a l’air flatteuse. Tu es parfait. Tu es différent. Tu n’es pas comme les autres. Tu es lumière. Tu es magie. Tu es l’exception.

Mais un piédestal reste une cage.

Quand je place quelqu’un au-dessus de moi, je rends aussi sa descente dangereuse. Chaque mouvement ordinaire devient une chute. Chaque limite devient une trahison.

Alors je pleure la perte d’une créature que j’ai inventée et j’appelle ce chagrin de l’amour.

Je ne veux plus de ça.

Je veux aimer les gens sur le sol.

Le sol est plus difficile. Le sol a de la vaisselle, de la circulation, de l’anxiété, des messages sans réponse, des corps, des factures, et des matins maladroits. Mais le sol est aussi l’endroit où les mains peuvent se toucher. C’est là que quelqu’un peut s’asseoir en face de vous, fatigué, et être encore aimé. C’est là qu’un non peut être entendu sans devenir une catastrophe.

Les gens que j’aime ont le droit d’être humains.

Ils ont le droit d’avoir des angles.

Ils ont le droit de ne pas encore savoir ce qu’ils ressentent.

Ils ont le droit d’avoir besoin de moi et de ne pas avoir besoin de moi.

Ils ont le droit d’être incohérents sans devenir faux.

Ils ont le droit d’être aimés sans être responsables de me sauver.

Et j’ai droit à la même miséricorde.

Cette partie compte aussi. Si je transforme tous ceux que j’aime en anges, je me transforme silencieusement en créature restée hors du paradis, essayant de gagner l’entrée en étant assez utile, assez drôle, assez patient, assez inoffensif.

Mais l’amour n’est pas censé être un bureau des visas.

Ce n’est pas un poste-frontière entre les dignes et les indignes. C’est deux êtres imparfaits qui choisissent la réalité plutôt que la mythologie.

Parfois, la lumière dans une personne est réelle. Je ne veux pas devenir cynique à ce sujet. Certaines personnes arrivent vraiment comme une fenêtre qui s’ouvre dans une pièce dont on avait oublié qu’elle contenait de l’air. Certaines personnes portent une chaleur qui apprend quelque chose à votre corps avant que votre esprit ait des mots pour cela.

J’y crois encore.

Je ne veux simplement pas confondre la lumière avec la perfection.

La poussière d’étoiles n’est pas propre. C’est du feu ancien et de la matière explosée. Peut-être est-ce pour cela qu’elle est belle : non parce qu’elle ne s’est jamais brisée, mais parce qu’elle s’est brisée si complètement qu’un jour elle est entrée dans une main humaine, un visage humain, un rire humain.

Les gens que j’aime sont faits de cela.

Pas de pierre d’autel.

De poussière d’étoiles.

Alors je veux les aimer les yeux ouverts. Voir la fatigue et faire quand même du thé. Voir la limite et ne pas la punir. Voir le défaut et ne pas le transformer en verdict. Voir la personne, pas la projection.

C’est moins dramatique que l’adoration.

Plus difficile aussi.

Mais plus doux. Pour eux, parce qu’ils peuvent enfin respirer. Pour moi, parce que je peux arrêter de m’agenouiller.

Les gens que j’aime ont le droit d’être humains.

Et si je peux m’en souvenir, peut-être que je pourrai enfin bien les aimer.

Je peux être bienveillant sans disparaître

Sun, 10 May 2026 12:14:00 GMT

Il y a une question sous la question.

À la surface, elle paraît ordinaire. Est-ce qu'elle m'aime bien ? Ai-je dit ce qu'il ne fallait pas ? Est-elle contrariée ? Devrais-je mieux m'expliquer ? Devrais-je être plus drôle, plus doux, plus calme, plus utile, moins en demande, plus homme, moins problème ?

Mais sous tout cela, il y a une question plus lourde.

Suis-je en sécurité, bon, suffisant, et pas comme les mauvais hommes ?

C'est la question que je retrouve sans cesse au fond du puits.

Pas parce que quelqu'un de vivant aujourd'hui l'y a déposée exprès. Personne ne m'a fait asseoir en me disant : tu dois traiter l'amour comme un examen moral. Personne n'a gravé la phrase sur un mur. C'était plus doux que cela. Plus ordinaire. Une maison a sa météo, et les enfants apprennent la météo avant d'apprendre la langue.

J'ai été élevé surtout par des femmes qui m'aimaient. Ma mère. Ma grand-mère. Pour moi, elles étaient presque mythologiques, non parce qu'elles étaient sans défaut, mais parce qu'elles étaient le monde. Elles étaient la tendresse, la nourriture, la protection, l'intelligence, le sacrifice, la chaleur. Elles étaient aussi blessées.

Mon père a été absent jusqu'à ce que je le retrouve bien plus tard. Il était, pour le dire doucement, un homme de nombreuses femmes. Cette absence a laissé une forme dans la maison. Autour de cette forme, une histoire a grandi : les hommes blessent, les hommes trahissent, les hommes prennent, les hommes partent, les hommes sont sales, les hommes sont faibles, les hommes sont dangereux.

Puis venait l'exception. Pas toi, mon fils. Pas toi.

Mais je ne crois pas qu'un enfant entende l'exception proprement. Un enfant entend d'abord le verdict, puis la note de bas de page. La nature masculine est dangereuse, et je dois prouver chaque jour que la mienne ne l'est pas.

Alors j'ai construit une religion privée de la bonté.

Un homme bon ouvre la porte. Un homme bon porte le sac. Un homme bon ne laisse jamais la femme qu'il aime souffrir seule. Un homme bon absorbe le fardeau. Un homme bon la fait rire. Un homme bon guérit. Un homme bon obéit. Un homme bon endure la douleur en silence. Un homme bon ne se plaint pas. Un homme bon n'a pas trop besoin. Un homme bon est assez utile pour être pardonné d'exister.

Cela semble noble jusqu'à ce que l'on voie le piège.

Si la bonté signifie un service sans fin, alors l'amour devient une dette. Si l'amour est une dette, alors chaque "non" ressemble à une facture impossible à payer. Si chaque limite ressemble à la preuve que tu as échoué, tu n'entends pas la personne devant toi. Tu entends le vieux tribunal qui rouvre.

C'est là que j'ai fait des erreurs.

Pas du genre bruyant. Pas la vengeance. Pas la cruauté. Mon échec est plus silencieux et plus humiliant.

Je m'effondre.

Un petit non tombe dans la pièce. Pas de cinéma. Pas de textos constants. Non, je suis occupée. Non, je suis fatiguée. Non, pas maintenant.

L'événement de surface est petit. L'explosion intérieure ne l'est pas.

Le téléphone devient un tribunal. Un message sans réponse devient une preuve. Une limite devient un verdict. Je commence à expliquer, non parce que j'ai quelque chose de nouveau à dire, mais parce que j'essaie de survivre au silence.

Ce n'est pas réparer.

C'est demander à une autre personne de me sauver de la possibilité que je sois mauvais.

Des excuses ne sont pas un sortilège. Elles ne convoquent pas le pardon. Elles ne rendent pas l'autre personne responsable de prouver que je suis bon.

La vraie réparation est moins théâtrale. Entendre non. Rester bienveillant. Ne pas faire payer à quelqu'un d'autre une vieille blessure.

Voici la phrase que j'essaie d'apprendre :

Je peux être bienveillant sans disparaître.

La bienveillance n'est pas l'obéissance. La douceur n'est pas l'effacement de soi. L'amour n'est pas une performance où je porte 100 % du poids jusqu'à ce que mon dos cède, puis où j'appelle cette rupture du dévouement.

Un homme bon ne disparaît pas dans le service rendu.

Un homme bon peut ouvrir la porte parce qu'il en a envie, non parce qu'il est terrifié à l'idée d'échouer à un test. Il peut porter un sac parce que c'est doux, non parce qu'un kilogramme dans la main de quelqu'un d'autre est une preuve contre lui. Il peut acheter un cadeau par joie, pas par panique. Il peut faire rire quelqu'un sans transformer le rire en preuve de sa valeur. Il peut protéger sans contrôler. Il peut s'excuser sans exiger qu'on le sauve immédiatement de sa culpabilité.

Et il peut entendre non.

Pas parfaitement. Pas sans douleur. Je ne prétends pas que le corps apprend à la vitesse du langage. Parfois, un petit non frappe encore comme le tonnerre. Parfois, la maladie, l'épuisement et la solitude rendent les vieilles pensées monstrueuses. Mais un sentiment n'est pas un commandement. Un système nerveux à batterie faible n'est pas un oracle.

J'ai donc besoin d'une pratique assez petite pour survivre à la vraie vie.

Respirer une fois.

Dire : "Je comprends. Pas de problème."

Faire avancer l'énergie.

Ne pas expliquer tout de suite.

Ne pas demander à l'autre personne de porter l'effondrement.

Laisser le non exister sans le transformer en fin du lien.

Cela paraît presque stupidement simple. Ça ne l'est pas. C'est toute une vie de météo à qui l'on demande de changer de direction, un souffle à la fois.

Mais peut-être que c'est cela, en réalité, la rédemption. Pas une montagne. Pas un gardien lumineux. Pas une seule phrase qui me sauve. Juste le refus répété de faire payer à quelqu'un d'autre une vieille blessure.

Je ne veux pas être l'un des mauvais hommes.

Mais je ne veux pas non plus construire toute ma vie autour de la preuve que je ne le suis pas.

Je veux quelque chose de plus net que cela. Plus calme. Plus humain.

Je veux être doux et avoir quand même un moi.

Je veux aimer sans me transformer en paiement.

Je veux être bienveillant sans disparaître.

Le pilier et le lierre

Sun, 26 Apr 2026 12:00:00 GMT

Les mathématiques discrètes sont pleines de petites choses qui ont l'air évidentes. C'est là le piège.

Vous êtes assis en amphi. Le professeur dessine quelque chose au tableau. Un invariant est une propriété P qui reste vraie à chaque point de contrôle d'une opération. Vous le notez, vous haussez les épaules, vous allez prendre un café. Et puis dix ans plus tard, vous déboguez un système distribué à 2 h du matin... et ce n'est qu'à ce moment-là que le mot commence à vouloir dire quelque chose pour vous.

Ceci est pour la version de vous qui est encore en amphi.

Un pilier dans un champ

Imaginez un vieux pilier de pierre, seul au milieu d'un champ. Rien autour. Rien qui lui arrive.

C'est ce que vous donne la définition du manuel. Juste le pilier.

Le professeur a oublié le lierre

Mon professeur était excellent, au passage. Le manuel ne ment pas. L'image est simplement incomplète.

Alors faites maintenant pousser du lierre sur le pilier. Des vrilles qui tirent sur la pierre. Des oiseaux qui nichent. Un touriste avec un marqueur. Un petit tremblement de terre. Une tempête. Deux cents ans de météo.

Le pilier est toujours là. De son point de vue, rien ne s'est passé.

Ça, c'est l'invariant.

Relisez maintenant la phrase du manuel — une propriété P qui reste vraie à chaque point de contrôle d'une opération. Le pilier est la propriété. Le lierre est l'opération. Le point de contrôle, c'est le moment où vous passez devant et regardez. Reste vraie, c'est juste une façon longue de dire le pilier se fiche du lierre.

Où vous allez continuer à le rencontrer

Une fois que vous avez le pilier, vous commencez à le voir partout.

Un invariant de boucle. Le corps de votre boucle est le lierre. Votre invariant est le pilier. Le corps peut le briser un instant, comme une vrille qui tire sur la pierre. Au point de contrôle suivant, le pilier est revenu là où il était.

Une transaction de base de données. Entre BEGIN et COMMIT, les données peuvent faire de la gymnastique. ROLLBACK est le jardinier qui arrive et arrache le lierre. Le pilier — votre état cohérent — tient encore debout.

ACID. Clés étrangères. Systèmes de types. Retentatives distribuées. Tous des piliers. Tous debout dans leur propre lierre.

Un pilier qu'on peut serrer dans ses bras

Un petit bonus, puisque vous lisez encore.

Il existe un concept frère appelé idempotence. Une opération idempotente est quelque chose que vous pouvez faire plusieurs fois, avec le même résultat que si vous ne l'aviez fait qu'une seule fois. Appeler ROLLBACK dix fois revient au même que l'appeler une fois. Mettre un interrupteur sur "on" dix fois revient au même que le mettre une fois.

Si l'invariance est le pilier qui ne change pas pendant que le lierre part dans tous les sens, alors l'idempotence est le pilier que vous pouvez serrer dans vos bras autant de fois que vous voulez, et qui ne s'en formalise pas.

Mettez les deux ensemble et vous obtenez l'étalon-or des systèmes tolérants aux pannes. Le réseau tombe ? Réessayez. Le serveur plante ? Réessayez. Vous finirez dans un état valide, et vous pouvez continuer à réessayer sans rien casser.

Un pilier qui survit au lierre et qui survit au fait d'être serré dans les bras mille fois. La plupart des infrastructures modernes sont discrètement construites là-dessus.

Une petite fin

C'est l'image que j'aurais aimé que quelqu'un dessine pour moi il y a dix ans.

Ce n'est pas grand-chose. Une image. Mais parfois, une seule image fait la différence entre un concept qui vit dans vos os et un concept qui vit dans une note de bas de page.

Si vous êtes étudiant, ou ingénieur junior, ou simplement quelqu'un qui hoche discrètement la tête devant le mot "invariant" depuis quelque temps... ceci est pour vous.

Le pilier se fiche du lierre. C'est toute l'histoire.

D'un outsider à un autre.

Là où toutes les sciences se rejoignent

Sat, 18 Apr 2026 12:00:00 GMT

Je ne suis pas mathématicien. Je ne suis pas philosophe. Je ne suis pas neuroscientifique. Je suis seulement quelqu'un qui aime penser... Et je n'arrête pas de surprendre les sciences en train de se faire des clins d'oeil quand elles croient que personne ne regarde.

Peut-être qu'elles lisent toutes le même livre. Et que la dernière page manque exprès.

Le langage est un code de très haut niveau

Le binaire a été le langage le plus bas, un jour. Puis l'assembleur. Puis le C. Puis mille autres. Chaque nouvel échelon n'est qu'une manière plus courte de dire une chose plus longue.

La parole humaine n'est qu'un échelon de plus sur la même échelle. Nous compilons nos pensées en mots. Les autres décompilent ces mots en pensées, dans leur propre tête. Le compilateur est avec perte. Toujours. C'est la nature même de la chose.

Une phrase est un programme de haut niveau. Une histoire est un système. Un proverbe est une petite fonction mise en cache qu'une évolution très ancienne a écrite.

La porte qui ne s'ouvre pas de l'intérieur

Gödel a prouvé quelque chose de cruel et de beau à la fois, tu sais. Tout système assez grand pour être intéressant ne peut pas prouver sa propre complétude depuis l'intérieur de lui-même. Il y a des choses vraies à ton sujet que tu ne peux pas atteindre avec tes propres outils.

Tarski l'a rendu plus tranchant. Le mot « vrai », dans n'importe quel langage, a besoin d'un langage plus grand pour le contenir. Tu ne peux pas définir la vérité depuis l'endroit où tu te tiens. Tu dois faire un pas dehors. Et dès que tu fais ce pas dehors, tu te retrouves dans un nouveau système qui a le même problème.

C'est un couloir de portes. Tu en ouvres une. Il y en a une autre.

C'est de la mathématique. Mais c'est aussi de la psychologie. C'est aussi de l'anthropologie. C'est aussi deux personnes qui essaient de se mettre d'accord sur ce que signifie un seul mot, sans jamais tout à fait y parvenir.

Personne n'est un oracle. Pas moi. Pas toi. Pas la personne la plus intelligente que tu aies jamais rencontrée. Ce n'est pas triste. C'est le seuil.

Alignement mutuel

Quand deux personnes parlent, aucune des deux n'est un oracle. L'alignement, ce n'est pas moi qui te corrige, ni toi qui me corriges. C'est nous deux qui posons des questions pour trouver l'écart invisible entre ce qui a été dit et ce qui était voulu.

La vérité ne se possède pas. La vérité se triangule.

Tu es mon méta-langage. Je suis le tien. Nous nous vérifions l'un l'autre pour des incomplétudes que nous ne pouvons pas voir seuls.

Le cerveau n'est pas paresseux

Notre cerveau fait de son mieux avec l'énergie qu'on lui a donnée. Il n'est pas paresseux. C'est un optimiseur. L'évolution ne l'a pas payé pour avoir raison. L'évolution l'a payé pour survivre avec un sac de noix et un petit lac.

L'astuce n'est pas de se battre avec le cerveau. L'astuce est de coopérer avec lui.

Une question l'allume. Une question est un minuscule repas gratuit. Une question, c'est ainsi qu'on réveille un esprit fatigué sans crier.

C'est aussi pourquoi le résumé est l'art le plus difficile. Résumer, c'est poser au matériau une seule question, et jeter tout ce qui n'est pas une réponse.

La Bulgarie parle

Nous avons un proverbe. Седем пъти мери, един път режи. Mesure sept fois, coupe une fois.

Il ne parle pas de lenteur. Il parle de savoir qu'une heure de réflexion t'épargne plus tard une année de mauvais code, ou de mauvais amour, ou de mauvaise carrière. Penser coûte peu. Couper coûte cher.

Nous en avons un autre. Рибата винаги започва да мирише от главата. Le poisson commence toujours à sentir par la tête.

Si le sommet est pourri, tout ce qui est dessous est déjà pourri aussi. Simplement, cela ne le sait pas encore.

Ces deux proverbes disent ce que Gödel disait, seulement en habits de paysan. Tu ne peux pas te prouver toi-même depuis l'intérieur. Vérifie-toi contre autre chose. Contre quelqu'un d'autre. Contre la réalité.

L'ingénierie, mais honnêtement

L'ingénierie, quand tu la pratiques honnêtement, devient silencieusement de la philosophie.

Tu construis toujours contre une spécification qui ne pourra jamais être complète. Gödel te l'a promis. Alors tu apprends à concevoir pour l'inconnu au lieu de prétendre qu'il n'existe pas. Tu poses une question de plus. Tu fabriques quelque chose qui pourra être corrigé quand la réalité arrivera.

Je ne parle pas d'ingénierie au sens étroit. Je parle de l'art de construire n'importe quoi qui doit tenir dans la réalité. Un produit. Une relation. Une vie. Le métier est toujours le même. Une ambition honnête face à des limites honnêtes.

C'est de la sagesse. Pas la sagesse des livres. La sagesse de regarder un problème dans les yeux et de dire : Je ne peux pas tout savoir de toi. Mais je vais construire quelque chose qui puisse quand même te contenir.

C'est à peu près ce que l'ingénierie a de plus proche de la sagesse.

L'excellence, c'est la marche

Lyndon B. Johnson a dit : « La plus noble quête d'aujourd'hui est la quête de l'excellence. »

Je pensais autrefois que l'excellence était une ligne d'arrivée. Elle ne l'est pas. L'excellence, c'est la marche. Mesurer sept fois. Poser une question de plus. Le respect pour la chose que tu fabriques, et aussi le respect pour la chose que tu deviens en la fabriquant.

L'excellence n'est pas un lieu où l'on arrive. L'excellence est simplement ce qui arrive quand on continue à demander.

Si tu ne peux pas l'expliquer à un enfant

Si tu ne peux pas l'expliquer à un enfant, tu ne le comprends pas toi-même.

La plupart des jours, j'échoue à ce test. Mais l'échec est utile. Si mon explication est longue, je n'ai pas compris. Si j'ai besoin de jargon, je n'ai pas compris. Si l'enfant s'en va encore confus, le problème, c'est moi. Pas l'enfant.

Tu vois, un enfant ne sait pas encore ce qu'il n'est pas censé demander. Un enfant posera la question que tu espérais que personne ne poserait. C'est pourquoi ils sont plus proches de la vérité que la plupart d'entre nous.

Là où toutes les sciences se rejoignent

Les mathématiques admettent l'incomplétude. La linguistique admet l'écart entre le signe et la chose. Les neurosciences admettent que le cerveau ne peut pas s'observer pleinement lui-même. La philosophie le dit depuis des siècles, sans être à la mode, patiemment. L'anthropologie regarde les humains tracer le même cercle dans mille sols de poussière différents. L'évolution murmure : ta meilleure pensée reste la pensée d'un singe, seulement mieux habillée.

Toutes, au plus profond, arrivent au même endroit. Elles se tiennent devant une porte qu'elles ne peuvent pas ouvrir de l'intérieur.

Je vais dire une chose maintenant, et tu peux la prendre comme tu veux.

Là où toutes les sciences se rejoignent, c'est là que Dieu vit.

Pas le Dieu d'un livre précis. Pas un Dieu d'un nom précis. Je veux dire seulement ceci. Au bord de chaque recherche honnête, il y a un silence qui n'est pas vide. Il y a un inconnaissable qui, d'une manière ou d'une autre, continue de nous enseigner.

Appelle-le Dieu. Appelle-le le Mystère. Appelle-le comme ton langage peut se le permettre. Il est toujours là. Il ne s'enfuit jamais. Et il est toujours de l'autre côté de la porte que tu ne peux pas ouvrir de l'intérieur.

La petite fin

Voilà pourquoi je pense autant. Voilà pourquoi je pose des questions auxquelles je ne peux pas répondre. Voilà pourquoi je continue à fabriquer des choses, même quand je sais que ces choses ne seront jamais complètes.

Parce que l'incomplétude n'est pas un bug.

C'est le seuil.

Et de l'autre côté de chaque seuil, quelque chose attend que quelqu'un frappe.

J'apprends encore à frapper.

Le modèle qui n'était pas là

Sat, 14 Mar 2026 00:00:00 GMT

Nous générions des images publicitaires avec Gemini 3 Pro. Classé #4 dans le classement Artificial Analysis. La qualité était vraiment impressionnante - meilleure adhérence au prompt, meilleure typographie, meilleure production créative que tout ce que nous avions essayé. Google était partout avec lui. Vidéos YouTube. Conférences. Séminaires. Articles de blog. "Le meilleur modèle de génération d'images au monde."

Je les ai crus. Les images étaient bonnes.

Puis un utilisateur a signalé que cloner une publicité prenait quatre minutes. J'ai vérifié. La génération elle-même se terminait en moins de trente secondes. Les trois minutes et demie restantes ? Le job réessayait contre un mur.

Resource Exhausted.

Google avait imposé un plafond dur à la génération d'images Gemini : deux requêtes par minute. Par projet. Globalement.

Deux. Pas deux cents. Pas vingt. Deux.

Nous avions généré 900 images la veille sans problème. Quelque chose avait changé de leur côté. Aucun avis, aucun email, aucune entrée dans le changelog. Juste un nouveau plafond, assez bas pour être atteint par deux utilisateurs qui cliquent en même temps.

Notre DevOps a soumis une demande d'augmentation de quota. Trente RPM. Raisonnable pour un SaaS en production. La réponse de Google :

"This gemini model is not available for quota increase."

Ils ont suggéré que nous passions à Imagen 4. Je l'ai vérifié.

Imagen 4 Ultra - classé #10. Imagen 4 Standard - #42. Imagen 4 Fast - #60.

Nous étions sur le #4. La suggestion de Google était une rétrogradation de quelque part entre six et cinquante-six places dans leur propre classement.

J'ai essayé tout ce qui m'est venu à l'esprit.

Passer à Gemini 3.1 Flash - classé #2, moitié moins cher, meilleur que ce que nous avions. Déployé en staging. Puis j'ai vérifié le quota. Même plafond de 2 RPM. Ce n'est pas par modèle. C'est par projet, par famille de modèle de base. Tous les modèles d'image Gemini partagent le même bucket.

Distribution multi-région - le quota est par région, donc répartir les requêtes sur cinq régions nous donnerait dix RPM. Sauf que les modèles d'image Gemini 3.x ne fonctionnent que sur l'endpoint global. Il n'y a pas d'endpoints régionaux. Les 2 RPM sur l'endpoint global sont le seul bucket qui existe.

Plusieurs projets GCP - chacun obtient ses propres 2 RPM. Techniquement, ça marche. Architecturalement, voilà à quoi ressemble le désespoir.

J'ai commencé à rechercher ce que vivaient les autres développeurs. La même histoire partout. Limite de 2 RPM non documentée. Posts de forum sans réponse de Google. Augmentations de quota approuvées qui renvoyaient quand même 429 à chaque appel. Nos $30K de dépense GCP mensuelle ? Ça n'aide pas. Les tiers PayGo standard excluent explicitement les modèles de génération d'images des bénéfices de throughput.

Google ne va pas augmenter cette limite.

Et ensuite la question intéressante : pourquoi pas ?

Gemini génère les images avec le même transformer autorégressif qui traite le texte. Ce n'est pas un modèle de diffusion. C'est le LLM complet, qui raisonne pixel par pixel à travers l'image. Chaque image brûle le même compute que des dizaines d'appels API texte.

À $0.067 par image, Google perd presque certainement de l'argent sur chaque génération. Le plafond de 2 RPM n'est pas un quota qu'ils ont oublié d'ajuster. C'est un étranglement calculé, parce que l'économie ne fonctionne pas.

Imagen 4 utilise une diffusion latente classique - moins chère de plusieurs ordres de grandeur à exécuter. C'est pour cela qu'il obtient 30-150 RPM et que Google pousse tout le monde vers lui. Le modèle cher reçoit le marketing. Le modèle bon marché reçoit le throughput.

Pensez à ce que cela signifie. Google a construit un modèle qui dominait tous les benchmarks. Ils l'ont commercialisé à chaque conférence, chaque keynote YouTube, chaque blog développeur. "État de l'art. Le meilleur au monde." Les développeurs l'intègrent en production. Les utilisateurs en dépendent. Puis : deux requêtes par minute, aucune augmentation disponible, utilisez plutôt notre moins bon modèle.

L'API existe. L'endpoint fonctionne. La démo est stupéfiante.

Mais vous ne pouvez pas vraiment l'utiliser.

Nous sommes passés à gemini-2.5-flash-image. L'ancien modèle. Le modèle ennuyeux. Celui dont personne ne fait de vidéos YouTube.

Il a 40 RPM. Il fonctionne.

Quatre leçons, condensées :

Le marketing n'est pas un produit. Dominer un classement ne veut pas dire que vous pouvez servir du trafic de production. Les benchmarks mesurent la qualité. Les limites de débit mesurent l'engagement.
La génération d'images autorégressive ne scale pas. Quand générer une image coûte autant que cent requêtes texte, aucun modèle économique ne survit à des limites de débit généreuses. L'économie est le signal.
Preview veut dire preview. Google peut changer les limites, tuer des modèles, ou vous rediriger vers des alternatives inférieures sans préavis. Si votre système de production dépend d'un modèle preview, votre système de production dépend du calendrier marketing de quelqu'un d'autre.
Le modèle ennuyeux fonctionne. Celui avec 40 RPM et aucune conférence servira vos utilisateurs pendant que le modèle de classe mondiale reste derrière une corde de velours à générer deux images par minute.

Le vendor lock-in le plus effrayant est celui qui commence par une démo à laquelle vous ne pouvez pas résister.

La ville qui n'était pas là

Sun, 08 Feb 2026 00:00:00 GMT

J'ai construit quelque chose qui tire des données d'une source, les nettoie, les présente mieux que l'original. Travail standard.

Puis j'ai interrogé la deuxième plus grande entrée du système. Tout le reste renvoyait des centaines de résultats. Celle-ci : zéro. Pas cassée. Simplement vide.

J'ai supposé que j'avais raté quelque chose. Vérifié mon code trois fois. Testé l'endpoint directement. L'entrée existe dans leur interface. Elle est juste... creuse.

C'est là que j'ai commencé à creuser.

La source avait l'air exhaustive. Large couverture, interface polie, API propre. Mais la participation volontaire signifie des trous qu'on ne voit pas depuis la documentation.

Trois concurrents avaient des données pour les mêmes entités. Des dossiers complets. Donc l'information existe quelque part.

Il ne manquait pas un endpoint. C'est l'endpoint qui manquait de réalité.

J'ai posé une question que personne n'avait pensé à poser : où vivaient ces données avant Internet ?

La réponse : dans des périodiques imprimés. Des archives. Des formats analogiques en circulation depuis les années 1800. Publiés trois fois par semaine. Pas de données structurées, seulement des documents sur un site web.

Alors j'en télécharge un. Prose institutionnelle dense, avis enfouis dans des services secondaires. Les données sont là.

Mes concurrents font cela manuellement depuis trente ans.

J'écris un scraper en un après-midi. En partie par curiosité, en partie par dépit.

Le parsing de documents, c'est là que les choses deviennent vraiment douloureuses.

Un seul mot se fait couper par un trait d'union conditionnel — Unicode U+00AD, invisible à l'œil, fatal pour chaque regex. Tu fixes l'écran en pensant que ton motif est faux. Il ne l'est pas. Un caractère fantôme se cache dans le texte. Le \w de JavaScript ne correspond pas aux caractères non-ASCII, donc des mots ordinaires deviennent impossibles à faire matcher. Les nombres contiennent des espaces fantômes venus du renderer : "20. 000" au lieu de "20.000."

Chaque bug prend plus de temps à trouver qu'à corriger. C'est toujours le ratio avec l'extraction de texte — 90% travail de détective, 10% code.

Dix enregistrements se matérialisent hors du bruit. Dates, identifiants, lieux — tout est là où cela doit être. Je le lance deux fois pour être sûr de ne pas halluciner. Même résultat. Cela marche vraiment.

Le parsing te montre ce qui est là. Je commence à chercher ce qui ne l'est pas. Les IDs sont séquentiels. Je les énumère.

53% sont morts. Le système purge les entrées terminées — pas d'archive, pas d'historique. Certains enregistrements existent, mais n'ont aucun document justificatif. La réponse : venez nous voir sur place. En 2026.

La source n'est pas une base de données. C'est une fenêtre — et quelqu'un continue de la fermer.

La première source de données a donné sa forme à l'architecture. La deuxième a cassé chaque hypothèse.

Il me fallait une deuxième architecture. Ce qui est une façon polie de dire que la première n'était pas vraiment une architecture — seulement une solution qui fonctionnait et qui se trouvait convenir à un cas. La source bizarre révèle la vérité : tu as construit pour les données que tu avais, pas pour celles que tu vas rencontrer.

Cette fois, j'en construis une vraie. Registry pattern, interfaces partagées, contrats de base qui permettent à chaque implémentation de rester fidèle à elle-même.

L'architecture est meilleure parce que j'ai attendu. Si je l'avais construite le premier jour, j'aurais conçu pour la seule source que je connaissais. La deuxième — l'étrange — m'a forcé à trouver ce qui compte vraiment.

On ne peut pas concevoir pour l'inconnu. Mais on peut refactoriser quand il arrive.

L'architecture m'a appris comment construire. Le marché m'a appris pour quoi construire.

J'entre sur un marché avec un acteur établi depuis trente ans. Leur technologie a l'air de dater de 2005. Leur avantage défensif n'est pas la technologie — c'est la confiance, la reconnaissance de marque, des décennies de données accumulées.

Le concurrent moderne s'est lancé il y a trois ans avec de l'IA et une interface élégante. Il a cassé les prix face à l'acteur historique. Trois ans plus tard, l'acteur historique domine toujours. Il s'avère que moins cher ne signifie pas automatiquement mieux positionné.

L'ancrage compte : le premier prix devient le point de référence. Facile à baisser plus tard, presque impossible à relever. L'abonnement n'est pas le produit — c'est la porte vers ce qu'il y a derrière.

Je fixe un prix élevé. Je peux toujours redescendre.

Quatre leçons, condensées :

Faire autorité ne veut pas dire être complet. La source primaire manquait tout un segment. Les données existaient — simplement pas là où quelqu'un les attendait.
La deuxième source révèle ton architecture. Tu n'apprends la vérité sur ton design que lorsqu'une chose refuse la forme que tu as construite.
Les données ne sont pas permanentes. Si tu en as besoin, sauvegarde-les. La source ne le fera pas.
Fixe ton prix pour ce que tu es en train de devenir, pas pour ce que tu es. L'abonnement est une porte. Construis ce qu'il y a derrière.

Le travail intéressant vit dans les interstices. Moi aussi.

La file qui ne s'est jamais arrêtée

Sat, 07 Feb 2026 00:00:00 GMT

Les emails échouaient. Cette partie était attendue — des identifiants SMTP cassés pendant une migration. Ce qui ne l'était pas : ils n'arrêtaient jamais d'échouer.

Tableau de bord Horizon : vert. Workers : en bonne santé. Redis : en lente croissance. Aucune alerte, aucune erreur dans les logs. Juste une accumulation silencieuse de jobs qui continuaient d'essayer, encore et encore et encore.

Je ne l'ai remarqué que parce que la mémoire Redis n'est pas redescendue après la correction de la configuration SMTP. Quelque chose était encore là-dedans, à mâcher des retries. Des milliers.

Je pensais que la file s'en chargerait. C'est le contrat : un job échoue, réessaie quelques fois, atterrit dans failed_jobs. On passe à autre chose.

Sauf si le job est un Mailable.

Quand vous envoyez un Mailable dans une file, Laravel l'enveloppe dans un job. Le maxTries de ce job vient de la propriété $tries du Mailable. Si vous ne la définissez pas — et pourquoi le feriez-vous, la documentation la mentionne à peine — elle est sérialisée comme null.

null ne veut pas dire « utiliser la valeur par défaut du supervisor ». null veut dire « sans limite ». Horizon voit null et pense : ce job veut réessayer pour toujours. Alors il le fait.

Il s'avère que c'est un bug connu. Laravel Horizon issue #1346. Le flag --tries du supervisor est ignoré quand le payload sérialisé du job contient maxTries: null. La déclaration propre au job gagne, et sa déclaration dit : ne jamais s'arrêter.

Vingt-neuf classes Mailable. Chacune sans propriété $tries explicite. Chacune potentiellement immortelle.

Le correctif est presque insultant de simplicité :

class WelcomeEmail extends Mailable implements ShouldQueue
{
    public int $tries = 2;
    public int $maxExceptions = 2;
}

Deux propriétés. Vingt-neuf fichiers. C'est tout.

Une tentative initiale, un retry, puis failed_jobs. Comme je pensais que cela avait toujours fonctionné.

Je le teste comme on testerait un piège à souris. Casser la configuration SMTP exprès. Envoyer un email. Regarder Horizon. Deux tentatives. Failed job. Terminé. Pas de fantômes dans la file.

Puis je corrige les vingt-huit autres.

Trois leçons, condensées :

null n'est pas « default ». Dans les payloads sérialisés des jobs, maxTries: null veut dire illimité. Votre configuration supervisor est une suggestion, pas une règle.
Les tableaux de bord verts mentent. Horizon montrait des workers en bonne santé, qui traitaient joyeusement des jobs qui ne finiraient jamais.
Les defaults des frameworks ne sont pas toujours sains. Laravel ne définit pas $tries sur les Mailables. Vous devez le faire. La documentation ne vous préviendra pas avant que vous ayez déjà un incendie.

Les bugs les plus effrayants sont ceux qui ressemblent à un fonctionnement normal. Celui-ci y ressemblait — pendant des semaines.

L'option nucléaire pour les suppressions massives : TRUNCATE + réinsertion (MySQL/InnoDB)

Sat, 13 Dec 2025 13:00:00 GMT

Vous devez supprimer des millions de lignes d'une table MySQL.

Vous attrapez :

DELETE FROM big_table WHERE some_condition;

Et puis vous regardez la barre de progression vieillir en temps réel.

Vous essayez d'être responsable et de le faire par lots :

DELETE FROM big_table WHERE some_condition LIMIT 10000;
-- repeat until done

Mieux. Toujours lent. Toujours bruyant. Toujours coûteux.

Si vous supprimez la majeure partie de la table (règle pratique : environ 80 % ou plus), il existe un autre geste, brutalement efficace :

Ne supprimez pas ce que vous ne voulez pas. Gardez ce que vous voulez, et atomisez le reste.

Je l'appelle l'option nucléaire : TRUNCATE + réinsertion.

Pourquoi `DELETE` reste lent (même par lots)

InnoDB ne « retire » pas les lignes. Il travaille.

Beaucoup de travail :

Opérations ligne par ligne : trouver, verrouiller, marquer comme supprimé.
Maintenance des index : chaque suppression touche chaque index secondaire.
Journalisation undo/redo : le moteur doit préserver la possibilité de rollback et de récupération.
Remous dans le buffer pool : vous salissez sans cesse des pages, vous en expulsez d'utiles.
Impact sur la réplication : de gros flux de suppressions sont une excellente façon de créer du retard sur les réplicas.

Petit calcul au dos d'une enveloppe :

27 M de lignes à environ 6 000 lignes/s ≈ 75 minutes.

Ce n'est pas un bug. C'est le modèle de coût que vous avez choisi.

L'option nucléaire : TRUNCATE + réinsertion

Cette technique renverse le modèle de coût.

Au lieu de payer par ligne supprimée, vous payez par ligne conservée.

Algorithme :

1) Copy the rows you want to keep into a temporary table
2) TRUNCATE the original table (fast)
3) Insert the preserved rows back into the original table
4) Drop the temp table

Et oui : on l'appelle « nucléaire » pour une raison. C'est volontairement brutal.

Pourquoi c'est rapide

Les gains sont mécaniques :

Opération	Coût approximatif	Pourquoi
`TRUNCATE`	~O(1)	supprime et recrée la table (au niveau des métadonnées)
`CREATE TABLE … AS SELECT`	O(k)	scan séquentiel + écriture en masse des lignes conservées
`INSERT … SELECT`	O(k)	insertion en masse ; pas de « taxe de suppression »

Pas de coût de suppression ligne par ligne. Pas de mises à jour d'index pour les lignes retirées (puisqu'elles disparaissent d'un seul coup).

Quand l'utiliser (et quand ne pas l'utiliser)

Utilisez-la quand

Vous supprimez la majeure partie de la table (encore une fois : environ 80 % ou plus, c'est la zone où cette approche commence à briller).
Vous pouvez définir proprement les « lignes à garder ».
Vous pouvez vous permettre une brève indisponibilité / fenêtre de maintenance.
La table n'est pas activement référencée par des clés étrangères depuis d'autres tables (ou vous pouvez gérer les contraintes en sécurité).
Vous avez assez d'espace disque pour la table temporaire.

Ne l'utilisez pas quand

Vous avez besoin de zéro downtime.
La table est fortement référencée par des clés étrangères que vous ne pouvez pas toucher.
Vous devez déclencher les triggers DELETE.
Vous ne supprimez qu'une minorité de lignes (la suppression par lots peut être le gain le plus simple).

Une règle de décision pratique

Si vous voulez une phrase à dire en revue :

Si la suppression retirerait la majeure partie de la table, arrêtez de supprimer. Préservez et reconstruisez.

Ou, si vous préférez l'ASCII :

How much are you deleting?

< 50%     -> chunked DELETE (and index-aware filters)
50–80%    -> measure both approaches
> 80%     -> TRUNCATE + reinsert (if constraints allow)

Implémentation (SQL)

Voici la forme minimale :

-- 1) Preserve the rows you want to keep
CREATE TABLE temp_preserved AS
SELECT * FROM big_table
WHERE preserve_condition;

-- 2) Nuke the table
TRUNCATE TABLE big_table;

-- 3) Restore preserved rows
INSERT INTO big_table
SELECT * FROM temp_preserved;

-- 4) Cleanup
DROP TABLE temp_preserved;

Deux notes importantes en production :

TRUNCATE est du DDL en MySQL. Il commit implicitement et vous ne pouvez pas le rollback comme une transaction normale.
Il vous faut une fenêtre de maintenance et une sauvegarde. Ce n'est pas un « essayons en live pour voir ».

Implémentation (Laravel/PHP)

Voici la version que j'utilise réellement quand j'en ai besoin :

protected function deleteViaTruncateAndReinsert(
    string $connection,
    string $tableName,
    string $preserveCondition
): int {
    $tempTable = "temp_preserved_{$tableName}_" . time();

    // You're about to do DDL. Be explicit that you're taking control.
    DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=0");

    try {
        DB::connection($connection)->statement("
            CREATE TABLE {$tempTable} AS
            SELECT * FROM {$tableName}
            WHERE {$preserveCondition}
        ");

        $preserved = DB::connection($connection)->table($tempTable)->count();

        DB::connection($connection)->statement("TRUNCATE TABLE {$tableName}");

        DB::connection($connection)->statement("
            INSERT INTO {$tableName}
            SELECT * FROM {$tempTable}
        ");

        DB::connection($connection)->statement("DROP TABLE {$tempTable}");
    } finally {
        DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=1");
    }

    return $preserved;
}

Petite énergie de canard en plastique : relisez la fonction et demandez à votre vous futur —

« Suis-je certain que cette table peut être vide pendant un instant ? »

Si la réponse n'est pas un oui sans ambiguïté, ce n'est pas le bon outil.

Les pièges à prévoir absolument

Réinitialisation de l'auto-increment

TRUNCATE réinitialise AUTO_INCREMENT. Si vous devez le préserver :

SELECT MAX(id) FROM big_table;
ALTER TABLE big_table AUTO_INCREMENT = <max_id + 1>;

Clés étrangères

Si d'autres tables référencent celle-ci, TRUNCATE peut être interdit ou dangereux. Ne vous contentez pas de « désactiver les checks » en espérant que tout ira bien.

Triggers

TRUNCATE ne déclenche pas les triggers DELETE. Si vous avez besoin de leurs effets de bord, vous revenez à DELETE.

Espace disque

Vous avez besoin de place pour le jeu de données conservé (la table temporaire). Vérifiez d'abord :

SELECT
  ROUND(data_length / 1024 / 1024 / 1024, 2) AS data_gb,
  ROUND(index_length / 1024 / 1024 / 1024, 2) AS index_gb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'big_table';

Réplication / binlog

C'est du DDL + une insertion en masse. Cela peut quand même créer du retard sur les réplicas. Faites-le intentionnellement, surveillez le retard, et ne faites pas semblant que c'est gratuit.

Si vous avez besoin d'un downtime (presque) nul

Cet article parle du marteau rapide.

Si vous avez besoin d'un scalpel, utilisez les outils faits pour cela :

pt-archiver (Percona Toolkit) pour des suppressions par lots avec un rythme respectueux des réplicas
stratégies de partitionnement (supprimer des partitions plutôt que des lignes)
approches par table fantôme + échange contrôlé (plus complexe, plus de pièces mobiles)

Dernière pensée

Ce n'est pas une astuce maligne. C'est choisir quel travail vous payez.

Refactoring de type 0 : l'étape avant la première étape

Sat, 13 Dec 2025 12:00:00 GMT

Il existe une catégorie de refactoring que les équipes font constamment, dont elles profitent immédiatement, et qu'elles ne nomment presque jamais.

C'est le travail que l'on fait juste avant de toucher au fichier qui fait peur. La demande de fonctionnalité vous force à entrer dans le module en bazar. L'incident arrive, et le bug se cache quelque part dans une méthode qui semble avoir son propre système météorologique.

Vous ne redessinez pas le système. Vous n'introduisez pas une nouvelle abstraction. Vous n'"améliorez" rien de façon maligne.

Vous rendez simplement le code assez lisible pour pouvoir travailler.

J'ai commencé à appeler cela le refactoring de type 0.

Le refactoring de type 0 est un nettoyage préparatoire, qui préserve le comportement, et qui rend le code plus facile à raisonner avant de faire des refactorings architecturaux, du travail de performance, ou du travail fonctionnel.

C'est l'étape "sécher le sol avant de refaire la cuisine". La plupart des équipes le font déjà informellement. Lui donner un nom en fait un outil partagé.

La vraie raison d'être du type 0 : les humains ont un budget de mémoire de travail

Voici la vérité brutale derrière l'idée :

Mon cerveau (et le vôtre) n'est pas construit pour debugger de façon fiable une méthode de 2000 lignes sous pression.

Ce n'est pas un défaut personnel. C'est simplement ainsi que fonctionne la cognition.

Debugger vous demande de garder en tête, en même temps :

le chemin d'exécution courant
l'état pertinent
ce que chaque variable veut vraiment dire
l'ensemble des branches possibles
les consequences de "si ceci arrive, alors..."

Dans du petit code, c'est gérable.

Dans du gros code avec une forte complexité cyclomatique, cela devient de la supposition probabiliste. Vous pouvez encore avoir de la chance, mais c'est coûteux et risqué, surtout pendant un hotfix.

Le type 0 est une réponse pratique : c'est la façon dont vous achetez rapidement de la clarté sans prendre le coût et le risque d'un "vrai refactoring".

Pourquoi l'appeler "type 0"

Le nom ne vient pas d'une grande théorie. Il vient d'un moment de forte pression.

Je travaillais sur un hotfix. Le bug était enfoui dans une méthode qui était, en pratique, son propre petit univers : environ 2000 lignes.

Le bug n'était pas conceptuellement difficile. La méthode, oui.

Chaque "que se passe-t-il si..." se ramifiait en dix questions de plus, et ces ramifications n'étaient pas du genre utile. C'était de la complexité incidente : bruit, répétition, noms peu clairs, et une structure qui ne correspondait pas au modèle mental nécessaire pour debugger.

Ce dont j'avais besoin n'était pas la perfection. J'avais besoin de debuggabilité :

moins de branches par écran
des "étapes" plus claires, avec des noms
moins de bruit
moins de temps passé à reparser ce que je venais de lire

Mais la pression du temps ne permettait pas un refactoring plus large ni une "refonte idiomatique". Le faire correctement aurait pris une demi-journée (ou plus), tests manuels inclus. Dans une fenêtre de hotfix, ce n'est pas de la discipline ; c'est un pari.

J'ai donc demandé à un LLM de suggérer des opportunités de refactoring pour la classe et cette méthode, sans lui dire pourquoi.

Il est revenu avec une liste de quatre "types" de refactoring. Tous raisonnables. Tous applicables. Tous trop coûteux pour ce moment-là.

Puis il a posé la question polie :

"Should I start with Type 1?"

C'est là que j'ai répondu :

"No. Let's start with Type 0."

Et j'ai défini le type 0 sur-le-champ : un ensemble contraint et mécanique de changements qui réduisent la complexité et augmentent la lisibilité sans changer le comportement ni l'architecture.

La méthode est devenue navigable. Mon cerveau pouvait de nouveau suivre l'exécution. J'ai trouvé le bug, je l'ai corrigé, et j'ai livré sans dégâts collatéraux.

C'est pourquoi j'aime le nom type 0 : c'est le refactoring que vous faites avant les "vrais" types de refactoring, surtout quand vous êtes sous pression et que vous avez besoin d'une façon sûre de créer vite de la clarté.

Le probleme que le type 0 resout

La plupart des conseils sur le refactoring supposent que vous pouvez déjà voir le design.

Dans les bases de code réelles :

les méthodes sont longues et multi-usages
les expressions répétées et la complexité incidente cachent l'intention
les variables sont cryptiques ($e, $tmp, $res)
le code mort et les imports inutilisés créent du bruit mental
la "forme" du code est si brouillonne que même de petits changements semblent risqués

Quand vous tentez un "vrai refactoring" par-dessus cela (frontières, patterns, déplacement de responsabilités), vous empilez l'incertitude sur l'incertitude :

vous ne pouvez pas facilement dire quel comportement vous préservez
vous ne pouvez pas prédire le rayon d'impact
les revues dégénèrent en débats subjectifs
les gens ont peur de toucher aux choses, et le désordre s'accumule

Le type 0 est la façon de réduire d'abord la charge cognitive. Il crée une base stable où un travail plus profond peut se faire en sécurité.

Utilisez le type 0 quand...

Le type 0 est le plus précieux quand :

vous devez debugger vite (hotfixes, incidents) et le code est trop grand ou trop ramifié pour raisonner dessus en sécurité
vous vous sentez "perdu dans la méthode" et relisez sans cesse la même section parce que la structure n'aide pas votre mémoire de travail
le code est correct mais illisible, et vous ne pouvez pas vous permettre de "nettoyer la logique", seulement de l'exposer
vous voulez réduire le risque avant un travail plus profond (vous savez que vous refactorerez plus tard, mais il vous faut d'abord une carte claire du comportement actuel)
vous voulez transformer du savoir tribal en structure lisible, pour que le debugging ne dépende pas d'une seule personne

Le type 0 n'est pas un luxe. Dans ces cas-là, c'est souvent le moyen le plus rapide de reprendre le contrôle.

Une définition que vous pouvez utiliser dans votre équipe

Le refactoring de type 0 est un ensemble de micro-refactorings qui améliorent la lisibilité et la maintenabilité sans changer le comportement ni l'architecture.

Il est volontairement contraint. Les contraintes sont la fonctionnalité.

Le type 0 se compose de quatre sous-patterns obligatoires :

0a. Extraction de méthodes
0b. Concision
0c. Empathie (lisibilité pure)
0d. Suppression du code mort

Et il suit trois règles strictes :

Aucun changement de comportement
Aucun changement architectural
Aucune amélioration "maligne" au-delà des quatre patterns

Si vous enfreignez ces règles, vous ne faites plus du type 0 : vous êtes passé dans une autre catégorie de travail, qui exige une coordination différente, une rigueur de revue différente, et souvent une stratégie de test différente.

Pourquoi le nommer ?

Parce que nommer change la façon dont les équipes se coordonnent.

"Je ne fais que du type 0 dans cette PR" indique aux reviewers ce qu'ils doivent regarder : préservation du comportement et lisibilité, pas débats d'architecture.
"Il nous faut du type 0 avant de refactorer ceci" est une admission honnête que le code n'est pas encore prêt pour un changement plus profond.
"Faisons le type 0 comme étape 0" crée un petit rituel qui vous évite de construire par-dessus le chaos.

Les quatre sous-patterns

0a. Extraction de méthodes (la fondation)

Objectif : découper les grandes méthodes en petites méthodes focalisées, pour qu'un humain puisse lire l'intention linéairement.

Règles pratiques :

décomposer les méthodes trop longues pour tenir dans la mémoire de travail
chaque méthode extraite doit faire une chose et porter un nom descriptif
extraire des étapes significatives, pas des morceaux arbitraires de N lignes

Pourquoi cela fonctionne (surtout pour le debugging) :

les méthodes plus petites créent des étiquettes pour le chemin d'exécution
un défilement de 2000 lignes devient une courte méthode d'orchestration que l'on peut parcourir mentalement
vous pouvez poser des breakpoints aux frontières sémantiques ("valider l'entrée", "construire la requête", "appliquer les filtres") au lieu de chasser à l'aveugle

0b. Concision (réduire la complexité incidente)

Objectif : retirer le bruit visuel pour que l'intention ressorte.

Exemples :

extraire les expressions répétées dans des variables locales
extraire les contextes de log / chaînes clés / fragments d'URL répétés dans des variables
préférer les fonctionnalités du langage qui communiquent directement l'intention
simplifier les interpolations trop verbeuses

Pourquoi cela fonctionne :

cela réduit la charge cognitive
cela rend les diffs plus petits et les changements plus sûrs
cela évite la dérive par copier-coller

0c. Empathie (lisibilité pure)

Objectif : ecrire pour le prochain humain, pas pour le compilateur.

L'empathie signifie :

utiliser des noms de variables descriptifs (éviter $e, $d, $tmp sauf si c'est vraiment évident)
maintenir une terminologie cohérente dans un module
renommer les noms trompeurs
rendre le code auto-documente

Test decisif :

Si quelqu'un lit ceci à 2 h du matin pendant un incident, est-ce que cela l'aidera à garder le chemin d'exécution en tête ?

0d. Suppression du code mort (retirer les mensonges)

Objectif : supprimer tout ce qui pretend compter mais ne compte pas.

Exemples :

méthodes privées inutilisées
imports inutilisés
anciennes approches commentées
helpers dépréciés que personne n'appelle

Pourquoi cela fonctionne :

moins de code signifie moins de choses a mal comprendre
les résultats de recherche deviennent fiables

Ce que le type 0 n'est pas

Le type 0 n'est pas :

changer les frontieres de services
introduire de nouvelles abstractions ou de nouveaux patterns
réarchitecturer un workflow
remplacer des bibliothèques
réordonner les responsabilités entre couches
"corriger" une logique que vous soupçonnez fausse (sauf si vous déclarez explicitement un changement de comportement et que vous le testez)

Si vous vous entendez dire :

"Tant que j'y suis, faisons aussi..."
"Ce serait plus joli si..."
"On devrait probablement refondre..."

Vous êtes peut-être en train de quitter le type 0. Ce n'est pas mauvais en soi, mais cela doit être intentionnel.

La promesse centrale : préservation du comportement (et comment la garder vraie)

Le type 0 ne fonctionne que si les équipes font confiance à la promesse.

Et oui, vous avez raison de vous méfier : l'extraction de méthodes peut accidentellement changer le comportement (retours anticipés, portée des variables, ordre d'évaluation, comportement des exceptions).

Le type 0 a donc besoin d'une discipline qui le garde honnête :

Extraire tel quel, puis renommer/nettoyer.

Premier passage : déplacer le code dans des méthodes sans changer la logique
Deuxième passage : appliquer concision + empathie
Troisième passage : retirer le code mort

Garde-fous pratiques :

ne réordonnez pas les conditions "pour la lisibilité"
ne remplacez pas la logique par une logique "équivalente" sauf si vous êtes hors du type 0
faites attention aux variables qui étaient auparavant dans une portée partagée
traitez les "petites" différences de flux de contrôle comme de vraies différences

Et si vous avez le moindre filet de sécurité, même mince :

lancez un test ciblé
rejouez le scénario qui échouait
validez le seul chemin que vous touchez

Le type 0 consiste à aller vite, mais vite en réduisant la complexité cognitive, pas vite en sautant la sécurité.

Le type 0 comme rituel d'équipe répétable

1) Décider le périmètre (un timebox aide)

Exemples :

"Faire le type 0 du hot path avant de debugger."
"Type 0 seulement sur le chemin touché par ce correctif."

2) Identifier la "colonne vertébrale" du code

Trouvez la ou les méthodes d'entrée et les points de branchement. Transformez cette colonne vertébrale en récit lisible par extraction.

3) Appliquer les quatre sous-patterns dans l'ordre

Extraction de méthodes → concision → empathie → suppression du code mort.

4) Garder une "checklist type 0" dans votre PR

Aucun changement de comportement (entrées/sorties inchangées)
Aucun mouvement architectural
Méthodes extraites et nommées comme des étapes significatives
Expressions répétées extraites quand cela améliore la clarté
Variables renommées ; terminologie cohérente
Code mort et imports inutilisés supprimés

Pensée de clôture

Le refactoring de type 0 est la promesse la plus simple qu'un développeur puisse faire :

"Je laisse ce code plus facile à travailler que je ne l'ai trouvé, sans changer ce qu'il fait."

Parfois, c'est "bon à avoir".

Et parfois, c'est la seule façon pour un humain d'avancer vite en sécurité dans un désordre très complexe, surtout pendant un hotfix.

Lavez une assiette de plus : une règle simple pour une base de code toujours propre

Thu, 24 Jul 2025 00:00:00 GMT

TL;DR : Traitez chaque changement dans votre base de code comme la préparation d'un repas. Vous allez salir quelques assiettes. Quand vous avez terminé, ne lavez pas seulement celles que vous avez utilisées : lavez-en une de plus. Avec le temps, ce petit surplus d'attention s'accumule en une cuisine (base de code) qui reste propre au lieu de glisser vers le chaos.

La métaphore : cuisine, assiettes et code

Imaginez une cuisine professionnelle. Chaque plat préparé salit quelques assiettes, même dans la brigade la plus ordonnée. Maintenant, imaginez qu'après avoir fini leur plat, chaque cuisinier lave exactement les assiettes qu'il a salies. La cuisine restera à la limite d'une propreté acceptable, mais l'entropie s'installera : un peu de crasse oubliée ici, une planche à découper tachée là. À la fin, le désordre s'accumule.

Inversez maintenant la règle : après avoir cuisiné, chaque chef lave une assiette de plus que celles qu'il a salies. Lentement, la cuisine devient plus propre qu'avant - pas seulement entretenue, mais améliorée. Il en va de même pour le logiciel : chaque tâche que vous prenez devrait ajouter au moins un minuscule surplus de propreté à la base de code - un test de plus, un nom plus clair, une fonction extraite, une dépendance morte supprimée. Cette habitude du "+1 assiette" est la manière dont une base de code reste saine.

J'appelle cela la règle Lavez une assiette de plus.

Échos du métier : vous êtes en bonne compagnie

Ce n'est pas une philosophie solitaire. Depuis des décennies, des figures du logiciel défendent des idées proches :

"Laissez toujours le camp plus propre que vous ne l'avez trouvé." C'est la classique Boy Scout Rule, popularisée dans le logiciel par Robert C. Martin. Même esprit : améliorer un peu, à chaque fois.
La dette technique comme métaphore (Ward Cunningham) : la dette accumule des intérêts. Ignorez-la, et la "cuisine" coûtera plus cher à utiliser demain. En rembourser une partie au fil de l'eau vous garde solvable.
Le refactoring comme petites étapes continues (Martin Fowler) : de minuscules changements qui préservent le comportement mais améliorent la conception. Les petits pas signifient peu de risque et un élan régulier.
"Make it work, make it right, make it fast" (Kent Beck) : d'abord la correction, puis la propreté, puis la performance. Laver cette assiette en plus vit dans la phase "make it right" - avant d'optimiser trop tôt.
La théorie des vitres brisées appliquée au code (Andrew Hunt et David Thomas) : le désordre visible invite davantage de désordre. Réparer une "vitre" avant que cela ne se propage protège le voisinage (la base de code).

Ces idées se renforcent mutuellement. Elles disent toutes la même chose : ne transmettez pas le désordre ; prenez un moment pour améliorer l'état des choses.

Pourquoi l'assiette en plus compte (même quand vous êtes occupé)

1. L'entropie est réelle

Laissé sans attention, le code ne reste pas neutre. Les noms dérivent, les patterns se fragmentent, les abstractions pourrissent. L'entropie est une force ; la seule contre-force est un rangement constant et incrémental. Votre +1 assiette est un renversement de micro-entropie.

2. La dette compose plus vite que vous ne le pensez

Le coût du changement augmente à chaque "on corrigera ça plus tard". Plus tard arrive rarement. Les intérêts se manifestent sous forme de fonctionnalités ralenties, de déploiements fragiles et de suites de tests auxquelles plus personne ne fait confiance. Laver une assiette en plus aujourd'hui abaisse le taux d'intérêt de demain.

3. Le signal social

Quand vos coéquipiers vous voient nettoyer derrière vous (et même un peu plus), la norme se déplace. Il devient crédible - et attendu - de laisser le code meilleur qu'on ne l'a trouvé. La culture suit le comportement.

4. De l'élan, pas du perfectionnisme

Ce n'est pas une excuse pour faire du yak shaving. Vous ne reconstruisez pas la cuisine en plein service. Vous passez l'éponge sur une assiette de plus - petit, sûr, rapide. C'est la clé pour garder la livraison sur les rails.

Comment pratiquer la règle Lavez-une-assiette-de-plus

Voici comment ancrer l'habitude sans faire dérailler le périmètre ni les délais.

1. Adoptez le "micro-refactoring" comme critère de terminé

Renommer une variable confuse.
Extraire une petite fonction pour réduire la complexité cyclomatique.
Supprimer du code mort ou des imports inutilisés.
Ajouter un test manquant pour un bug que vous venez de corriger.
Mettre à jour une documentation ou une section de README qui vous a fait peur une minute.

Le critère : Si cela prend plus que quelques minutes, ce n'est pas une assiette - c'est tout le lave-vaisselle. Différez-le. Capturez-le sous forme de ticket.

2. Utilisez les pull requests comme déclencheur de nettoyage

Chaque PR peut laisser le camp plus propre :

Exiger une case "Qu'avez-vous nettoyé ?" ou une courte note.
Encourager les reviewers à demander de petits rangements en parallèle de leur revue.
Célébrer les PR qui incluent ce polissage supplémentaire (les mentions en standup vont loin).

3. Automatisez les assiettes faciles

Hooks pre-commit pour le formatage et le linting.
Analyse statique pour signaler les méthodes complexes ou les longues listes de paramètres.
Vérificateurs de dépendances pour les bibliothèques obsolètes.

Laissez les balais automatisés retirer les désordres triviaux pour que les humains puissent se concentrer sur la logique et la conception.

4. Inscrivez-la dans les normes de l'équipe

Ajoutez la règle à l'accord de travail ou au manuel d'ingénierie de votre équipe.
Suivez les victoires de micro-refactoring en rétrospective si vous voulez une preuve mesurable.
Programmez parfois en pair ou en mob pour diffuser l'habitude (et le courage).

5. Sachez quand ne pas laver

Parfois, la cuisine est en feu : la production est tombée, ou une démo commence dans quelques heures. En urgence, cassez la pile d'assiettes sales s'il le faut. Mais revenez-y après la crise. La règle n'est pas un dogme ; c'est une discipline.

La limite : une assiette, pas l'évier

Le scope creep se déguise souvent en artisanat. Votre travail est de vous arrêter à "une assiette de plus". Si ce petit refactoring révèle une odeur plus profonde, notez-la et avancez. Mettez la correction plus profonde au parking :

Créez un ticket libellé refactor: ou techdebt:.
Liez-le au code, aux tests ou au module concerné.
Ajoutez une courte note expliquant pourquoi cela compte.

Vous avez fait votre devoir : vous avez repéré le désordre, lavé une assiette et laissé des instructions pour la suite.

Exemple : transformer une fonction confuse en fonction testable

Avant :

function processOrder($order) {
    if(!$order->id) throw new Exception('No ID');
    $tax = 0;
    if ($order->country === 'BG') {
        $tax = $order->total * 0.20;
    } else if ($order->country === 'DE') {
        $tax = $order->total * 0.19;
    }
    // Lots more branching...
    // Sends email, writes to DB, calls payment gateway…
}

Assiette lavée :

/**
 * Calculate VAT for an order based on country.
 * Pure function: given (total, country) -> VAT amount.
 */
function vatFor(string $country, float $total): float {
    return match($country) {
        'BG' => $total * 0.20,
        'DE' => $total * 0.19,
        default => 0.0,
    };
}

Maintenant, votre fonction principale appelle vatFor() au lieu d'inliner la logique. Vous avez ajouté un micro-test pour vatFor(). C'est une assiette de plus - simple, contenue, utile.

Dernières pensées

Une assiette de plus, c'est minuscule. C'est justement le point. Vous n'avez pas besoin de refactorings héroïques pour garder une base de code saine ; vous avez besoin d'une culture de soin petit, constant. Faites-en une habitude, intégrez-la à votre processus, et dans un an vous vous demanderez pourquoi votre cuisine n'est pas un désastre - parce que vous ne l'avez jamais laissée le devenir.

Appel à l'action : La prochaine fois que vous touchez un fichier, demandez-vous : "Quelle assiette supplémentaire puis-je laver avant de commit ce changement ?" Puis faites-le. Répétez. Changez la culture, une assiette impeccable à la fois.

Sources et lectures complémentaires

Robert C. Martin ("Uncle Bob") - Boy Scout Rule : "The Boy Scout Rule" dans 97 Things Every Programmer Should Know.
Ward Cunningham - métaphore de la dette technique : l'explication originale de Cunningham sur la Technical Debt, sur le site de Martin Fowler.
Martin Fowler - micro-refactoring continu : le livre de Fowler, Refactoring: Improving the Design of Existing Code.
Kent Beck - "Make it work, make it right, make it fast" : une explication du mantra par Ron Jeffries.
Andrew Hunt et David Thomas - Broken Windows in Software : le concept est détaillé dans leur livre, The Pragmatic Programmer.
Entropie logicielle et maintenance : une bonne lecture sur le sujet : "Entropy in Software and the Broken Window Theory."

PHP 8.5 : tour des fonctionnalités à venir

Sun, 20 Jul 2025 00:00:00 GMT

TL;DR Échelle de hype (mon classement joueur)

Pipe Operator (|>) – Bonheur de transformation linéaire et lisible. Aimant à refactorings.
Attribut #[\NoDiscard] – Transforme « on a oublié d'utiliser le retour » en avertissement immédiat. Se marie merveilleusement avec les pipes.
Closures statiques / callables first-class dans les expressions constantes – Cartes de stratégie et arguments d'attributs au moment de la compilation. Bonbon pour frameworks.
php --ini=diff – Diff instantané de dérive d'environnement. Vous évite la spéléologie de config.
Attributs sur constantes globales et de classe – Des métadonnées partout (flags, dépréciations, tags sémantiques).
array_first() / array_last() – Évident, révélateur d'intention, non mutateur. Adieu effets de bord de reset().
get_exception_handler() et compagnie – Introspection pour gestion d'erreurs en couches (victoire niveau framework / infra).
Douceurs Intl (IntlListFormatter, Locale::isRightToLeft()) – UX localisée plus fluide avec presque aucun code.
Levenshtein conscient des graphèmes – Fuzzy matching utilisateur qui respecte vraiment les caractères humains.
Objet Directory + introspection cURL / build / divers – Polissage de cohérence et d'opérabilité.

(Oui, votre ordre peut différer. C'est le plaisir : en débattre autour d'un café.)

1. Pipe Operator (`|>`) – « Easy Peasy Lemon Squeezy »

Les appels imbriqués et les variables temporaires jetables ? Disparus. Le pipe operator prend la valeur à gauche et la transmet comme premier argument au callable à droite. Vous lisez de haut en bas, la logique coule comme de la prose, et l'intention vous saute au visage.

Avant (marelle de variables) :

$email = $request->string('email');
$email = trim($email);
$email = strtolower($email);
sendEmail($email);

Avant (imbrication de parenthèses) :

sendEmail(strtolower(trim($request->string('email'))));

Après (zen du pipe) :

$request->string('email')
    |> trim(...)
    |> strtolower(...)
    |> sendEmail(...);

Pourquoi c'est important :

Flux de données visible. Plus de pile mentale de retours imbriqués.
Se combine très bien avec de petits helpers purs.
Encourage à décomposer les transformations en fonctions / closures nommées.
Satisfait automatiquement #[\NoDiscard], puisque la valeur continue d'avancer.

Conseil de style : Gardez chaque étape sans effet de bord ; réservez le pipe final à un effet (par exemple persister, envoyer, émettre), pour repérer visuellement où la « pureté » se termine.

2. `#[\NoDiscard]` – L'intention militarisée

Combien de bugs subtils étaient juste « on a appelé le truc mais oublié d'utiliser ce qu'il retournait » ? Marquez une fonction ou une méthode avec #[\NoDiscard] pour exiger que son résultat soit utilisé, ou ignoré consciemment via un cast (void).

#[\NoDiscard("Token must be used – did you forget to persist or dispatch?")]
function issueAuthToken(User $user): string {
    return generateTokenFor($user);
}

issueAuthToken($user); // ⚠ Emits warning in 8.5
(void) issueAuthToken($user); // Explicit intentional discard

Patterns :

Objets de résultat (Result, Outcome, ValidationReport).
Builders immuables (qui retournent une nouvelle instance à chaque appel).
Garde de sécurité / d'effets de bord (tokens, signatures).

Synergie : Dans une pipeline, le retour de chaque étape est naturellement consommé par la suivante, donc les oublis accidentels disparaissent.

3. Closures statiques dans les expressions constantes – « Attends... quoi ?! »

Vous pouvez maintenant intégrer des closures statiques (ou des callables first-class) dans les expressions constantes, valeurs de propriété par défaut, arguments d'attributs et tableaux de paramètres par défaut. Pensez registres de stratégie au moment de la compilation, sans gymnastique de câblage au démarrage.

class Sanitizers {
    public const STAGES = [
        'trim' => trim(...),
        'upper' => static function (string $v): string { return strtoupper($v); },
    ];
}

// Attribute example
#[Validate(
    rules: [
        'title' => static function(string $v){ return mb_strlen($v) > 0; },
        'slug'  => static function(string $v){ return preg_match('/^[a-z0-9-]+$/', $v); },
    ]
)]
class Article {}

Pourquoi ça claque :

Élimine les recherches dans un service locator pour les stratégies simples.
Pousse les tables de correspondance pures dans des constantes (immuables + cacheables).
Les attributs peuvent maintenant encapsuler directement de la logique, pas seulement des métadonnées scalaires.

Contrainte : Doit être static ; pas de $this, pas de capture de variable. Si vous avez besoin de contexte, passez-le explicitement plus tard.

4. `php --ini=diff` – Rayon X de dérive de config

Fatigué du « Mais ça marche en staging » ? Ce flag CLI affiche seulement les directives INI qui diffèrent de la valeur par défaut.

php --ini=diff
# memory_limit: "128M" -> "-1"
# max_execution_time: "30" -> "0"

Cas d'usage :

Étape CI pour imposer une base cohérente.
Vérification rapide quand un worker se comporte bizarrement.
Triage d'anomalies mémoire / temps.

Astuce pro : capturez la sortie dans le contrôle de version pour les bases runtime.

5. Attributs sur constantes globales et de classe – Des métadonnées partout

Les constantes passent de « valeur idiote » à « participante annotée ». Décorez les flags de domaine, feature toggles, avis de dépréciation, sémantique d'unité, directement au site de définition.

#[Deprecated("Use FEATURE_NEW_PRICING instead")]
public const FEATURE_OLD_PRICING = 1;

#[Unit("ms")]
public const DEFAULT_TIMEOUT = 250;

Levier framework : Auto-découvrir les dépréciations, alimenter des catalogues de fonctionnalités, générer de la doc, ou faire respecter une politique via réflexion.

6. `array_first()` / `array_last()` – L'évidence existe enfin

Arrêtez les acrobaties de pointeur (reset(), end()) ou les slices juste pour regarder. Ces helpers expriment l'intention directement et ne modifient pas l'état interne du tableau.

$firstUser = array_first($users, default: null);
$lastUser  = array_last($users, default: null);

Pattern de refactoring : Cherchez reset( / end( / les array_slice(..., 0, 1) compliqués, puis remplacez par des appels sémantiques. Diffs plus propres, moins de micro-bugs.

7. `get_exception_handler()` (et meilleures traces fatales) – Upgrade d'observabilité

Développeurs framework / infra, réjouissez-vous : vous pouvez maintenant introspecter le gestionnaire d'exceptions actif. Chaîner, envelopper, restaurer ou décorer sans jongler avec un global fragile.

$previous = get_exception_handler();
set_exception_handler(function(Throwable $e) use ($previous) {
    logToSentry($e);
    if ($previous) { $previous($e); }
});

Combiné à des stack traces plus riches pour les erreurs fatales, cela accélère fortement les post-mortems de production.

8. Améliorations Intl – Listes et direction à hauteur humaine

IntlListFormatter produit des conjonctions / disjonctions charmantes et conscientes de la locale, sans logique de colle faite maison.

$f = new IntlListFormatter('pt_PT', 'conjunction');
echo $f->format(['Lisboa', 'Porto', 'Coimbra']); // "Lisboa, Porto e Coimbra"

$fOr = new IntlListFormatter('en_US', 'disjunction');
echo $fOr->format(['apples', 'bananas', 'cherries']); // "apples, bananas, or cherries"

Combinez avec Locale::isRightToLeft() (ou locale_is_right_to_left()) pour basculer automatiquement la direction de mise en page.

9. Levenshtein conscient des graphèmes – Vraie distance de chaînes utilisateur

Quand les utilisateurs tapent des emoji, accents, caractères combinants, la distance en octets ou en codepoints naïfs ment. grapheme_levenshtein() respecte les caractères visibles.

grapheme_levenshtein('café', 'cafe'); // 0 – visually same after accent

Suggestions de recherche, fuzzy match et flux de connexion tolérants aux fautes deviennent linguistiquement justes.

10. Le défilé du polissage

Objet Directory : opendir() vous donne maintenant un vrai objet (sécurité de type, extension future) au lieu d'une ressource legacy.

Améliorations cURL : Meilleurs share handles + introspection multi-handle = meilleure réutilisation des connexions dans les workers longue durée (pensez RoadRunner, Swoole) et réglage de performance plus fin.

PHP_BUILD_DATE : Vérification rapide de « quel âge a ce binaire ? » pour les scripts d'audit. Parfait pour s'assurer que les noeuds d'une flotte ne traînent pas silencieusement derrière.

Mémo de synergie des fonctionnalités

Objectif	Combiner
Pipeline de transformations avec usage imposé	`	>`+`#[\NoDiscard]`
Validation déclarative / cartes de stratégie	Closures statiques en expression constante + attributs de constantes
Refactors plus sûrs des tableaux legacy	`array_first()/array_last()` + typage de retour strict
Triage d'incident de production	Meilleures traces fatales + `php --ini=diff` + `get_exception_handler()`
Polissage UX international	`IntlListFormatter` + détection de direction + distance de graphèmes

Plan d'adoption pratique

Introduire le Pipe Operator progressivement : commencez dans les couches de normalisation de données pures ; imposez le style (un seul effet de bord à la fin) en code review.
Annoter les APIs critiques avec #[\NoDiscard] : ciblez d'abord sécurité, persistance et builders ; mesurez les volumes d'avertissements en CI.
Refactorer les tables de stratégie : déplacez les maps de callables simples dans des tableaux public const avec closures statiques, pour un coût de démarrage nul.
Vérifications de dérive de config : ajoutez un job CI qui capture la sortie de php --ini=diff ; alertez sur les changements inattendus.
Balayage des métadonnées : taguez les constantes avec dépréciation / unités / feature flags pour alimenter l'outillage interne.
Nettoyage d'extraction aux bords des tableaux : codemod pour remplacer les patterns qui manipulent les pointeurs.
Superposition des gestionnaires d'erreurs : enveloppez les handlers globaux existants avec get_exception_handler() pour l'observabilité (instrumentation Sentry/new relic).
Améliorations i18n : remplacez le code manuel de « colle de liste » par IntlListFormatter ; testez l'autosélection de layout RTL.
Qualité du fuzzy matching : là où du texte multilingue généré par les utilisateurs apparaît (recherche, tagging), benchmarkez la distance graphème vs classique.
Script d'audit runtime : loggez PHP_BUILD_DATE + php --ini=diff chaque jour pour détecter les conteneurs vieillissants.

Mini playground « Show Me »

#[NoDiscard("Hash must be stored or compared")]
function password_hash_safe(string $plain): string {
    return password_hash($plain, PASSWORD_DEFAULT);
}

function sanitize_email(string $raw): string { return strtolower(trim($raw)); }

$request->string('email')
    |> sanitize_email(...)
    |> fn($email) => (strlen($email) > 5 ? $email : throw new InvalidArgumentException('Too short'))
    |> sendEmail(...); // Each stage consumes prior result – no discard.

class Rules {
    public const VALIDATORS = [
        'title' => static function(string $v){ return $v !== ''; },
        'slug'  => static function(string $v){ return (bool) preg_match('/^[a-z0-9-]+$/', $v); },
    ];
}

foreach (Rules::VALIDATORS as $field => $check) {
    if (! $check($data[$field] ?? '')) {
        throw new RuntimeException("Invalid $field");
    }
}

Quand ne pas attraper le jouet brillant

Une seule transformation triviale ? Un pipe peut être excessif ; strtolower($x) reste très bien.
Closures pleines de contexte ? Méthodes régulières avec injection de dépendances > hacks de closures statiques.
Codebase legacy en pleine montée de version ? Introduisez une fonctionnalité à la fois pour éviter la surcharge cognitive.

Récapitulatif du modèle mental

Fonctionnalité	Modèle mental central
`	>`	Enfilage linéaire de valeur ; éliminer imbrication et temps
`#[\NoDiscard]`	Forcer une consommation intentionnelle (utiliser ou ignorer avec `(void)`)
Constantes de closures statiques	Registre de stratégie immuable préparé au chargement
Attributs sur constantes	Canal de métadonnées first-class pour outils et politiques
`array_first()/last()`	Accès déclaratif et non mutateur aux extrémités
`php --ini=diff`	Lentille de delta de config vs base par défaut
`get_exception_handler()`	Introspecter et envelopper le flux global d'exceptions
Ajouts Intl	Intelligence locale intégrée pour remplacer la colle artisanale
Distance graphème	Opérations sur caractères perçus humainement plutôt que codepoints bruts
Polissage build & ressources	Standardisation et introspection incrémentales

Vibes finales

PHP 8.5 ne hurle pas avec des changements de paradigme : il murmure des victoires ergonomiques implacables. Le combo pipe operator + #[\NoDiscard] poussera à lui seul votre code vers une intention plus claire. Ajoutez des closures au moment de la compilation et des attributs de constantes, et vos frameworks / composants deviennent plus déclaratifs, plus explicites, plus découvrables. Bam bam boom : ship it.

À vous de jouer : Choisissez une fonctionnalité (probablement le pipe), appliquez-la chirurgicalement dans un petit module, mesurez la clarté dans les retours de code review, puis étendez. L'élan bat les réécritures big-bang.

Restez joueurs, refactorez bravement, et, oui, écrivez à vos Taylors quand vous trouvez les moments « Wait, WHAT?! ».

Happy coding.

Qu’est-ce qu’une « bonne » couverture de code ? Un guide de terrain

Tue, 15 Jul 2025 00:00:00 GMT

Qu’est-ce qu’une « bonne » couverture de code ? Mon guide de terrain pour arrêter les bugs sans gaspiller le temps d’ingénierie

Chaque fois que je lance npm run coverage ou phpunit --coverage, la même question revient :

« Bon… 74 %. Est-ce que c’est assez ? »

La blogosphère du développement logiciel hurle « 100 % ou rien ! ». Pendant ce temps, launchdarkly.com me rappelle poliment que 100 % exécuté ≠ 100 % testé.
J’ai passé des semaines à courir après la métrique brillante, et encore plus de semaines à déboguer d’autres problèmes. Voici le juste milieu éprouvé sur le terrain auquel je suis arrivé.

Pourquoi 100 % de couverture est un mirage

En théorie, 100 % d’exécution des lignes signifie « aucun bug caché ». En pratique :

Rendements décroissants : passer de 90 % à 95 % double souvent votre suite de tests pour une réduction du risque à un chiffre.
Fausse confiance : un test qui appelle une fonction sans aucune assertion compte quand même comme couvert.
Réalité business : chaque test en plus, c’est du temps non consacré aux fonctionnalités demandées par vos clients.

Les gens de l’aérospatiale peuvent viser 100 % — c’est une question de vie ou de mort. Pour le reste d’entre nous, ~80 % est la ligne du 80/20. C’est là que la plupart des projets se regroupent après calcul du ROI. testdevlab.com parle d’une plage de 70 à 90 % pour exactement cette raison.

Le tableau pratique que j’utilise

Couverture	Ma traduction	Action
100 %	« Nous sommes une bibliothèque qui fait voler des fusées »	Accepter le labeur.
90 % +	« Une bibliothèque dont dépend beaucoup d’argent »	Module hautement prioritaire seulement.
80 %	Livrer, surveiller, puis itérer.
60–70 %	Barrière de merge — faire échouer la PR si le nouveau code vous fait passer en dessous.
< 50 %	Week-end de dette technique — pivoter d’abord vers les chemins critiques.

J’ai volé ces chiffres au guide interne d’Atlassian : 60 % « acceptable », 75 % « louable », 90 % « exemplaire ». Ça marche dans toutes les rétros.

Comment j’atteins 80 % sans pleurer (playbook TypeScript)

Jest + Istanbul dès le départ

Barrière de couverture en CI
dans jest.config.js, j’ajoute :

coverageThreshold: {
  global: 80,
  '**/src/core/**': 90
}

Viser les chemins chauds côté utilisateur, pas le logger boilerplate Redux.

Comment j’atteins 80 % dans Laravel (playbook PHP)

Installer PCOV pour la vitesse en dev, Xdebug pour les données de branches en CI.

PHPUnit + ces valeurs par défaut dans phpunit.xml :

<filter>
  <whitelist processUncoveredFiles="true">
    <directory suffix=".php">./src</directory>
  </whitelist>
</filter>

Score de mutation > nombre de lignes avec Infection — c’est comme ça que je repère les lignes « couvertes mais pas vraiment testées ».

4 règles avec lesquelles mon équipe vit

Nouveau code = tests. Couverture du diff ≥ 90 % avant merge.
Refactoriser d’abord, tester ensuite. Le code intestable est déjà une dette.
Faire échouer le build, pas les humains. Baisser la barrière de 5 % chaque année plutôt que de casser les équipes avec des tableaux de bord rouges.
Mesurer les bugs en production — si la couverture est à 85 % mais que les incidents montent, la couverture n’est pas la coupable ; les assertions le sont.

TL;DR (pour les dirigeants et les recruteurs aussi)

Ne me demandez pas un « chiffre magique ». Demandez :

Quelles parties du produit ne peuvent pas casser ?

Couvrez celles-là à 90 %. Donnez au reste des tests smoke sains. Utilisez la couverture de code comme un projecteur, pas comme une ligne d’arrivée, et faites confiance aux bugs que vous attrapez, pas aux chiffres dont vous vous vantez.

Que le tableau de bord de couverture soit vert — vos clients ne le verront jamais, mais leur barre d’erreur restera vide.

— Fin du coup de gueule, retour à l’éditeur.

Mon guide essentiel pour des revues de pull request efficaces

Sun, 06 Jul 2025 00:00:00 GMT

Comme quelqu'un qui écrit et relit beaucoup de code, j'ai appris que les revues de pull request (PR) sont plus que des vérifications de bugs : elles parlent de propriété partagée, de transfert de connaissances, et de meilleure construction du code ensemble. Voici un guide concis et pratique pour rendre les PR utiles et moins douloureuses.

1. Les objectifs d'une bonne revue

Chercher l'amélioration, pas la perfection
Le code parfait n'est pas réaliste : visez un code meilleur. Si une PR améliore la lisibilité, la maintenabilité ou la justesse, approuvez-la même s'il reste de petits ajustements de style. Utilisez « Nit: » pour les suggestions facultatives. google.github.io
Propriété partagée et mentorat
Traitez les PR comme du code collectif. Laissez des retours pédagogiques (« Nit: tu pourrais utiliser X ici... »), accompagnez les développeurs juniors, et restez aussi ouverts à apprendre d'eux.

2. Se préparer avant de relire

Auteurs : faites une auto-revue. Lancez les tests, les linters et les formatters. Donnez du contexte dans les descriptions de PR et annotez la logique complexe.
Reviewers : lisez d'abord la description. Comprenez le « pourquoi » avant de plonger dans le code.

3. Garder les PR petites et ciblées

Les données montrent que la qualité de revue chute nettement au-delà d'environ 400 LOC et 60 minutes. atlassian.com devzery.com mikeconley.ca
Repères :

Restez sous 200-400 LOC par PR. mikeconley.ca
Gardez les revues sous 60 minutes.
Pour les grosses fonctionnalités, utilisez des PR empilées (DB → API → UI).

4. Assigner les reviewers avec soin

Un reviewer principal, idéalement avec une connaissance du domaine.
Deux reviewers maximum, pour éviter la dilution de responsabilité. support.smartbear.com abseil.io slab.com
Faites tourner les reviewers pour partager les connaissances et garder un bus-factor sain.

5. Ce qu'il faut vérifier dans une PR

Utilisez cette checklist mentale :

Justesse : est-ce que cela remplit les exigences et gère les cas limites ?
Conception : est-ce bien structuré et idiomatique ?
Lisibilité : noms clairs, logique simple, style cohérent.
Sécurité : valider les entrées, assainir les sorties, éviter les fuites.
Performance : surveiller les boucles coûteuses et les requêtes N+1.
Tests : couverture des cas centraux, limites et erreurs.
Conformité : documentation, CI, licences et formatage corrects.

Cela nous aide à attraper davantage de problèmes tôt, surtout les problèmes de maintenabilité. google.github.io developers.google.com google.github.io

6. Tirer parti de l'automatisation

Laissez les outils faire le travail ingrat :

Linters (ESLint, RuboCop, SonarQube)
Formatters (Prettier, Black)
Pipelines CI avec tests, couverture et contrôles de sécurité

Cela permet aux reviewers humains de se concentrer sur la logique, l'architecture et la nuance.

7. Donner des retours constructifs et bienveillants

Soyez respectueux : ponctuez les suggestions, pas les personnes.
Soulignez ce qui est bien fait.
Soyez actionnable : expliquez le pourquoi et suggérez le comment.
Préfixez les points non bloquants par « Nit: » ou « Optional: ». atlassian.com google.github.io
Gardez les discussions objectives (« nous » > « tu »). Évitez la critique personnelle.
Proposez une discussion synchrone si un va-et-vient bloque le processus. atlassian.com

8. Mesurer le processus, pas les personnes

Indicateurs utiles pour suivre les tendances (pas pour juger les individus) :

Temps de rotation (PR ouverte → merge)
Vitesse d'inspection (< 300-500 LOC/h au mieux) atlassian.com developers.google.com mikeconley.ca
Densité de défauts (problèmes par LOC)
Couverture de revue entre composants
Nombre de commits de suivi

Utilisez ces observations pour affiner votre flux de travail, par exemple en insistant sur des PR plus petites, en améliorant la documentation ou en formant l'équipe sur les modules délicats, mais ne liez jamais ces métriques aux évaluations de performance. mikeconley.ca google.github.io bssw.io

9. Considérations propres aux langages

Des paradigmes différents demandent une attention adaptée :

PHP/JavaScript/TS : gestion de l'asynchrone, XSS, principes SOLID
Python : gestion des ressources (with), PEP 8, pièges des arguments par défaut
Haskell/Scala fonctionnels : signatures de types, pureté, immuabilité, vérification des macros
C/C++ : sûreté mémoire, pointeurs, RAII
Java : null-safety, concurrence propre, SOLID
Lisp : documentation des macros, typage dynamique, motifs idiomatiques

Adaptez les checklists à votre stack et impliquez des experts pour les langages moins familiers.

Bonus : sources recommandées pour aller plus loin

Google, The Standard of Code Review – Philosophie de la santé du code et du mentorat. google.github.io
Google Code Review Developer Guide – Conseils sous forme de checklist. bssw.io
Étude SmartBear/Cisco – Résultats empiriques sur la taille et le timing des PR. mikeconley.ca
Atlassian, « 5 Code Review Best Practices » – Conseils pratiques de style et de travail en équipe. atlassian.com
Flux PR de Blockly – Processus de revue par étapes dans le monde réel. developers.google.com

Pensées finales

Les revues de PR bien faites sont plus que des barrières de qualité : ce sont des moteurs d'apprentissage, de collaboration et d'excellence technique. En combinant une culture respectueuse, de bons outils, un processus éclairé par les données et des retours réfléchis, les revues de code deviennent des discussions utiles, pas des corvées.

Bonne revue !

N'hésitez pas à laisser un commentaire ou à me contacter si vous voulez creuser davantage ou partager vos propres astuces de revue !

Détection du tabagisme avec l’Apple Watch : construire Still Mirror (Swift, SWT)

Tue, 13 May 2025 00:00:00 GMT

L’idée de vraiment comprendre nos habitudes, surtout celles que nous accomplissons presque inconsciemment, m’a toujours fasciné. Et si nos objets connectés pouvaient offrir un miroir doux, sans jugement, à ces schémas ? Cette question a déclenché le projet « Still Mirror » : une tentative de détecter passivement les épisodes de tabagisme ou de vapotage à partir des riches données physiologiques d’une Apple Watch, sans demander de saisie manuelle à l’utilisateur. Il ne s’agit pas de construire une énième app de sevrage, mais plutôt un outil de pure conscience, sans filtre.

Le défi : un murmure dans une symphonie de bruit

Le défi central est immense : comment distinguer la signature physiologique subtile d’un épisode de tabagisme/vapotage parmi la myriade d’autres activités quotidiennes et réponses corporelles ? Le stress, une marche rapide, un bruit soudain, ou même une tasse de café peuvent tous provoquer des changements transitoires de la fréquence cardiaque (FC) et de la variabilité de la fréquence cardiaque (VFC). Le signal que nous cherchons ressemble souvent à un murmure dans une symphonie de bruit physiologique.

Mais pour vraiment isoler ces événements fugitifs, il me fallait une technique de traitement du signal plus sophistiquée.

Fig 1. – L’écosystème de développement Apple : Xcode, Swift et HealthKit sont essentiels pour donner vie à « Still Mirror » sur l’Apple Watch.

Choisir la boîte à outils : écosystème Apple et Swift

Pour un projet destiné à l’Apple Watch, le choix de l’écosystème est clair :

Xcode et Swift : l’environnement de développement natif pour les plateformes Apple. M’y engager signifiait plonger plus profondément dans Swift, un langage que je trouve élégant et puissant, et naviguer dans les subtilités de Xcode.
HealthKit : le framework d’Apple est la porte d’entrée vers les flux de données essentiels : fréquence cardiaque, VFC (SDNN/RMSSD), SpO2 (particulièrement pertinent pour combustion vs vapotage) et niveaux d’activité. La conception de HealthKit centrée sur la confidentialité est primordiale pour une app qui manipule des données aussi sensibles.
Limites de watchOS : développer pour la montre signifie équilibrer en permanence les fonctionnalités avec les contraintes de ressources : autonomie de batterie et capacités de traitement en arrière-plan restent toujours au premier plan.

Le cœur algorithmique : transformée en ondelettes stationnaire (SWT)

L’analyse traditionnelle des séries temporelles peine souvent avec les signaux non stationnaires, c’est-à-dire les signaux dont les propriétés statistiques (comme la moyenne et la variance) changent dans le temps. Les données physiologiques sont notoirement non stationnaires. C’est là que la transformée en ondelettes stationnaire (SWT) entre en jeu.

Contrairement à la transformée en ondelettes discrète (DWT) standard, qui est variante par translation (ce qui signifie qu’un petit décalage du signal d’entrée peut modifier fortement les coefficients d’ondelettes), la SWT est invariante par translation. Cela la rend plus robuste pour analyser des signaux où le moment exact des événements est crucial, mais peut varier légèrement.

Pourquoi la SWT pour ce problème ?

Localisation temps-fréquence : la SWT peut décomposer un signal en différentes bandes de fréquences tout en préservant l’information temporelle. Cela signifie que nous pouvons chercher des caractéristiques fréquentielles précises (par exemple, des bouffées soudaines d’activité haute fréquence dans la FC, ou des changements spécifiques dans les bandes de fréquence de la VFC) qui apparaissent à des moments précis.
Débruitage : les signaux physiologiques sont bruités. La SWT peut aider à séparer le signal « vrai » sous-jacent du bruit aléatoire en analysant les coefficients d’ondelettes à différentes échelles.
Détection d’événements transitoires : elle est particulièrement efficace pour identifier les changements abrupts, les pics ou les événements transitoires dans un signal, exactement ce que l’on pourrait attendre de la réponse physiologique aiguë à la nicotine.

Fig 2. – Visualiser la transformée en ondelettes stationnaire qui décompose un signal en ses composantes fréquentielles au fil du temps, pour aider à la détection de motifs.

En substance, la SWT agit comme un ensemble sophistiqué de filtres, nous permettant de « voir » dans les données de FC, de VFC et potentiellement de SpO2 des motifs que le bruit ou les tendances de long terme pourraient masquer. Nous pouvons chercher des « formes » caractéristiques ou des changements d’énergie dans certaines sous-bandes d’ondelettes qui correspondent à la secousse physiologique.

Le parcours de développement : des données à la détection

Collecte de données (HealthKit) : mettre en place une récupération fiable des données HealthKit en arrière-plan, en respectant les autorisations de l’utilisateur et en gérant efficacement les mises à jour.
Prétraitement du signal : nettoyer les données entrantes de FC, VFC et SpO2. Cela inclut la gestion des points de données manquants et peut-être un premier filtrage avant d’appliquer la SWT.
Application de la SWT : appliquer la transformée en ondelettes stationnaire à des segments de séries temporelles physiologiques. Cela implique de choisir une ondelette mère appropriée (par exemple Daubechies, Symlet) et un niveau de décomposition.
Extraction de caractéristiques à partir des coefficients d’ondelettes : c’est là que la magie (et beaucoup d’expérimentation) arrive. Au lieu de regarder directement les valeurs brutes de FC/VFC, nous analysons les coefficients SWT. Les caractéristiques pertinentes pourraient inclure :
- l’énergie dans certaines bandes de coefficients de détail autour du moment d’un événement suspecté ;
- les propriétés statistiques (variance, kurtosis) des coefficients ;
- la corrélation croisée entre les coefficients d’ondelettes de différents signaux physiologiques (par exemple FC et VFC).
Logique/modèle de détection : au départ, il pourrait s’agir d’un système à règles cherchant des motifs précis dans les caractéristiques d’ondelettes extraites (par exemple : « un pic d’énergie significatif dans les coefficients de détail de la FC à l’échelle X, coïncidant avec une chute nette d’énergie dans les coefficients de détail de la VFC à l’échelle Y, pendant une période de faible activité physique »). À terme, cela pourrait évoluer vers un modèle d’apprentissage automatique entraîné sur ces caractéristiques.
Score de confiance : comme décrit dans mon algorithme MVPS, générer un score de confiance pour chaque événement détecté est crucial, afin de refléter la force et la clarté de la signature.
Implémentation de l’app watchOS : faire tourner l’algorithme de détection principal sur l’Apple Watch, en optimisant l’autonomie (par exemple, traitement des données par lots, déclenchement intelligent de l’analyse).
App compagnon iOS : afficher la chronologie des événements détectés, fournir des aperçus et gérer les réglages. La synchronisation des données via WatchConnectivity est essentielle ici.

Santé et considérations éthiques : la philosophie du « miroir »

Il est vital de répéter que « Still Mirror » est conçu comme un outil de conscience, pas comme un dispositif médical ni comme un programme de sevrage.

Confidentialité d’abord : tout le traitement, surtout le travail algorithmique sensible, devrait idéalement se faire sur l’appareil. L’accès aux données HealthKit est strictement fondé sur les autorisations.
Aucun jugement : l’interface de l’app et les aperçus qu’elle fournit doivent rester neutres, se contentant de refléter des schémas sans conseil prescriptif ni honte.
Précision et transparence : les utilisateurs doivent comprendre les limites de l’app. Les faux positifs et faux négatifs sont inévitables avec une détection passive aussi complexe. Il est important d’être transparent sur la confiance accordée aux détections.
Autonomie de l’utilisateur : le but est de fournir aux utilisateurs des données sur leur propre corps et leurs propres habitudes, afin de les aider à prendre leurs propres décisions éclairées.

Apprendre Swift et naviguer dans l’écosystème Apple

Pour les développeurs venant surtout d’autres horizons (comme mes racines PHP/Laravel), plonger dans Swift, SwiftUI, Xcode et les contraintes spécifiques du développement watchOS représente une courbe d’apprentissage réelle. Les frameworks d’Apple portent une philosophie particulière. Gérer les cycles de vie d’app, les tâches en arrière-plan, les requêtes HealthKit et la communication entre appareils (WatchConnectivity) a ses propres motifs et ses propres « façons Apple » de faire les choses. Pourtant, la richesse de la documentation, la force de la communauté et la puissance de Swift rendent le voyage gratifiant.

Conclusion : le potentiel d’un observateur silencieux

« Still Mirror » reste une exploration, une entreprise exigeante pour repousser les limites de ce que la captation passive sur un objet connecté grand public peut accomplir. La transformée en ondelettes stationnaire offre une piste prometteuse pour disséquer des signaux physiologiques complexes et révéler les signatures subtiles que nous cherchons.

Le parcours ne consiste pas seulement à coder en Swift et à se battre avec Xcode, mais aussi à descendre dans la théorie du traitement du signal, à comprendre la physiologie humaine et à considérer soigneusement les implications éthiques d’une telle technologie. Que « Still Mirror » devienne une app largement utilisée ou reste une exploration technique complexe, le processus lui-même témoigne de l’intersection fascinante entre IA, santé et technologie personnelle. Il s’agit d’essayer de construire cette surface calme et réfléchissante — un miroir immobile — pour une meilleure conscience de soi.

Que pensez-vous de l’usage d’un traitement avancé du signal comme la SWT pour détecter passivement des habitudes ? J’aimerais beaucoup lire vos réflexions dans les commentaires ci-dessous !

Corriger le Bluetooth de l'émulateur Android sur Mac M1 avec Bumble et l'API 32

Mon, 14 Apr 2025 00:00:00 GMT

Si vous développez avec Bluetooth sur un Mac M1/M2/M3 et que vous essayez de faire fonctionner la radio Bluetooth de votre machine hôte dans l'émulateur Android, vous avez probablement déjà souffert un peu. Ce qui semble devoir être simple se transforme souvent en tunnel frustrant de connexions ratées, d'erreurs cryptiques et de documentation qui s'arrête juste avant l'endroit utile. Je viens de traverser exactement cette bataille, et après plusieurs murs, j'ai fini par trouver une combinaison avec la pile Bluetooth Python Bumble qui fonctionne vraiment.

Ce n'est pas encore un guide théorique de plus ; c'est le récit pas à pas de ce qui a échoué et, surtout, de ce qui a réussi pour relier le Bluetooth de mon Mac Pro M1 (via un dongle USB externe dans mon cas, même si le principe pourrait s'appliquer aux radios internes) à un émulateur Android 12L (API 32).

L'objectif : du vrai Bluetooth dans l'émulateur

L'objectif était simple : faire utiliser à l'émulateur Android le contrôleur Bluetooth physique de mon Mac au lieu de son contrôleur virtuel limité. C'est crucial pour tester des applications qui interagissent avec de vrais appareils Bluetooth.

L'outil : entre en scène Bumble

Bumble est une puissante pile Bluetooth en Python. Son outil clé pour cette tâche est bumble-hci-bridge, qui peut se connecter à une interface HCI physique (Host Controller Interface) d'un côté et l'exposer via différents transports (comme TCP ou gRPC) de l'autre.

Tentative n°1 : la méthode socket QEMU (le premier essai logique)

À partir de connaissances générales sur QEMU et de quelques anciens guides, la première approche consistait à utiliser des flags de l'émulateur pour connecter directement un port série virtuel (adossé à une socket TCP) au bridge HCI.

Démarrer le bridge (mode serveur TCP) : Nous avons connecté Bumble au dongle physique (qui, étonnamment, fonctionnait mieux avec usb:0 qu'avec son VID:PID spécifique usb:0b05:17cb sur ma machine — les bizarreries du M1 !) et l'avons fait écouter sur un port TCP.
```
# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge usb:0 tcp-server:0.0.0.0:6789
# Output showed '>>> connected' twice - success connecting to USB and starting TCP server.
```
Lancer l'émulateur avec des flags QEMU : Nous avons modifié le script de lancement de l'émulateur (en ciblant d'abord l'API 34) pour ajouter des flags -qemu qui dirigeaient un port série virtuel (virtserialport) vers un périphérique de caractères (chardev) adossé à une socket TCP connectée au bridge.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -qemu \
    -device virtio-serial-device \
    -device virtserialport,chardev=bt,name=bt \
    -chardev socket,id=bt,host=localhost,port=6789 \
    ...
```
Le résultat ? Succès partiel, échec final : Avec lsof, nous pouvions voir que le processus QEMU de l'émulateur établissait bien une connexion TCP vers le bridge Bumble. Pourtant, la pile Bluetooth Android à l'intérieur de l'émulateur n'envoyait jamais réellement de commandes HCI dessus. Activer ou désactiver le Bluetooth dans les réglages Android ne faisait rien. Les logs du bridge restaient silencieux après la connexion initiale. Impasse.

Tentative n°2 : le bridge Netsim par défaut (en suivant la documentation Bumble)

La documentation de Bumble mentionne un bridge vers l'interface gRPC « Netsim » de l'émulateur. Netsim (et son cœur, Root Canal) est le système plus récent de contrôleur Bluetooth virtuel de l'émulateur.

Démarrer le bridge (mode contrôleur Netsim) : Nous avons configuré le bridge pour agir comme un contrôleur Netsim, écouter sur le port gRPC par défaut (8554), et se connecter au dongle physique.

# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
# Output showed '>>> connected' twice - success connecting to USB and starting Netsim gRPC server.

Lancer l'émulateur (backend par défaut) : Nous avons remis le script de lancement en arrière (toujours avec l'API 34) pour retirer les flags -qemu et ajouter -packet-streamer-endpoint default, afin de nous assurer qu'il tente d'utiliser le backend Netsim.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -packet-streamer-endpoint default \
    ...
```
Le résultat ? Aucune connexion : Cette fois, l'émulateur démarrait, mais le bridge Bumble ne montrait aucun signe d'une connexion gRPC entrante depuis l'émulateur. Les logs de l'émulateur ne révélaient pas d'erreur de connexion évidente, mais le Bluetooth restait inutilisable. Encore une impasse.

Tentative n°3 : rétrograder l'API + endpoint Netsim explicite (la bonne !)

Fig1. – Un paysage surréaliste où des câbles réseau ratés pendent entre des formations rocheuses Apple et Android, tandis qu'un seul pont de corde marqué Bumble relie les deux avec succès et laisse passer des paquets de données lumineux.

Des recherches web ont révélé des signalements d'instabilité générale avec le Bluetooth sur les émulateurs API 33/34 et de possibles problèmes dans la manière dont l'émulateur découvre ou se connecte au backend Netsim, surtout quand un outil externe tente de l'intercepter. La clé semblait être de dire explicitement à l'émulateur où se trouvait le serveur gRPC Netsim et d'essayer un niveau d'API plus ancien.

Démarrer le bridge (mode contrôleur Netsim, port explicite, usb:0) : Comme dans la tentative n°2, en veillant à ce qu'il écoute sur un port connu (8554) et se connecte au dongle physique avec l'index (usb:0) qui fonctionnait de manière fiable.
```
# In Terminal 1: (Keep this running!)
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```

Modifier et lancer l'émulateur (API 32, endpoint explicite) : Nous avons créé un AVD API 32 (Android 12L) avec Google Play Services (gplay_32_arm). Nous avons modifié le script de lancement pour cibler cet AVD et, point crucial, remplacé le flag -packet-streamer-endpoint de default par l'adresse exacte de notre bridge.

# Snippet from the *successful* launch script (see full script below):
API_LEVEL="32"
AVD_NAME="gplay_${API_LEVEL}_arm"
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
BUMBLE_NETSIM_GRPC_PORT="8554"
...
emulator -avd "$AVD_NAME" ... \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    ...

Le résultat ? Réussite ! Cette fois, ça a marché !
- Le terminal bumble-hci-bridge a commencé à afficher des logs de connexion gRPC depuis l'émulateur peu après le lancement.
- Une fois l'émulateur démarré, activer le Bluetooth dans les réglages Android a provoqué une avalanche de commandes HCI (Reset, Read Version, Set Event Mask, etc.) dans le terminal du bridge.
- La recherche d'appareils depuis l'émulateur utilisait bien la radio Bluetooth physique du Mac via le dongle ASUS.

La recette gagnante : pas à pas

Voici la procédure exacte qui a fonctionné sur mon Mac Pro M1 avec un dongle externe ASUS USB-BT500 :

Installer Bumble :

python3 -m pip install bumble
# Potentially install libusb if needed: brew install libusb

(Optionnel mais recommandé) Désactiver la prise en charge USB BT native de macOS : À exécuter une seule fois, puis redémarrer.
```
sudo nvram bluetoothHostControllerSwitchBehavior="never"
```
Démarrer le bridge Bumble Netsim : Ouvrez un terminal et lancez (gardez-le ouvert) :
```
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```
(Vérifiez qu'il affiche >>> connected deux fois.)
Préparer le script de lancement de l'émulateur : Enregistrez le script complet fourni ci-dessous sous le nom launch_gapps_avd_api32.sh (ou similaire). Assurez-vous qu'il cible un AVD API 32 (il en créera un nommé gplay_32_arm s'il n'existe pas) et qu'il utilise explicitement -packet-streamer-endpoint localhost:8554. Rendez-le exécutable (chmod +x launch_gapps_avd_api32.sh).
Lancer le script : Ouvrez un nouveau terminal et exécutez le script :
```
./launch_gapps_avd_api32.sh
```
Vérifier : Une fois l'émulateur démarré :
- Consultez le terminal bumble-hci-bridge pour voir le trafic gRPC et HCI.
- Allez dans Android Settings -> Bluetooth et activez-le.
- Essayez de scanner ou d'appairer un appareil.

Le script de lancement qui a réussi (API 32, endpoint Netsim explicite)

#!/bin/bash

# Script to setup and launch a Google Play Android emulator (API 32) on macOS M1/ARM64
# Uses explicit Netsim endpoint for Bumble bridge compatibility.

set -e # Exit immediately if a command exits with a non-zero status.

# --- Configuration ---
API_LEVEL="32" # Target Android API Level (Android 12L)
AVD_NAME="gplay_${API_LEVEL}_arm" # Name for the Android Virtual Device
IMAGE_TAG="google_apis_playstore" # Image type with Google Play Store
ARCH="arm64-v8a" # Architecture for Apple Silicon
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
DEVICE_DEF="pixel_6a" # A common modern Pixel device definition
BUMBLE_NETSIM_GRPC_PORT="8554" # Port where bumble-hci-bridge Netsim controller is listening

# --- Find Android SDK ---
ANDROID_SDK_ROOT="${ANDROID_HOME:-${ANDROID_SDK_ROOT:-$HOME/Library/Android/sdk}}"

if [ ! -d "$ANDROID_SDK_ROOT" ]; then
    echo "❌ Error: Android SDK not found at '$ANDROID_SDK_ROOT'" >&2
    echo "   Please install Android Studio or set ANDROID_HOME/ANDROID_SDK_ROOT." >&2
    exit 1
fi
echo "▶️ Using Android SDK at: $ANDROID_SDK_ROOT"

# --- Define Tool Paths ---
CMDLINE_TOOLS_BIN="$ANDROID_SDK_ROOT/cmdline-tools/latest/bin"
PLATFORM_TOOLS_DIR="$ANDROID_SDK_ROOT/platform-tools"
EMULATOR_DIR="$ANDROID_SDK_ROOT/emulator"

SDKMANAGER="$CMDLINE_TOOLS_BIN/sdkmanager"
AVDMANAGER="$CMDLINE_TOOLS_BIN/avdmanager"
EMULATOR="$EMULATOR_DIR/emulator"
ADB="$PLATFORM_TOOLS_DIR/adb"

# --- Check Essential Tools ---
if ! command -v sdkmanager &> /dev/null; then echo "❌ Error: sdkmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v avdmanager &> /dev/null; then echo "❌ Error: avdmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v emulator &> /dev/null; then echo "❌ Error: emulator not found. Check Android Emulator installation and PATH." >&2; exit 1; fi
if ! command -v adb &> /dev/null; then echo "❌ Error: adb not found. Check SDK Platform-Tools installation and PATH." >&2; exit 1; fi
echo "✅ Basic SDK tools found in PATH."

# --- Stop Currently Running Emulators ---
echo "▶️ Stopping any currently running emulators..."
RUNNING_EMULATORS=$(adb devices | grep 'emulator-' | cut -f1)
if [ -n "$RUNNING_EMULATORS" ]; then
    for emu_id in $RUNNING_EMULATORS; do
        echo "   Stopping $emu_id..."
        adb -s "$emu_id" emu kill || echo "   (Failed to kill $emu_id, may already be stopped)"
        sleep 1 # Small delay
    done
    # Give ADB server time to recognize disconnection
    sleep 3
    echo "   Emulators stopped."
else
    echo "   No emulators appear to be running according to 'adb devices'."
fi
echo "✅ Emulator check/stop finished."


# --- Install/Update Required SDK Packages ---
echo "▶️ Ensuring required SDK packages are installed..."
# Accept licenses non-interactively
yes | sdkmanager --licenses > /dev/null || echo "   (Ignoring potential license script errors)"

# Install platform-tools, emulator
sdkmanager "platform-tools" "emulator"

# Install the Google Play system image for API 32
echo "▶️ Attempting to install/update Google Play system image: $SYSTEM_IMAGE_PKG"
if ! sdkmanager "$SYSTEM_IMAGE_PKG"; then
    echo "❌ Error: Failed to install required system image '$SYSTEM_IMAGE_PKG'." >&2
    echo "   Please check available images using: sdkmanager --list | grep 'system-images;android-${API_LEVEL};.*${ARCH}'" >&2
    exit 1
fi
echo "✅ System image package '$SYSTEM_IMAGE_PKG' present."

# --- Check if AVD Exists, Create ONLY if Missing ---
echo "▶️ Ensuring AVD '$AVD_NAME' exists..."
if ! avdmanager list avd --compact | grep -q "^${AVD_NAME}$"; then
    echo "   AVD '$AVD_NAME' not found. Creating..."
    # Using 'echo no' usually prevents hardware profile creation prompts. Pipe empty string for potential licenses.
    echo "" | avdmanager create avd --force --name "$AVD_NAME" --package "$SYSTEM_IMAGE_PKG" --device "$DEVICE_DEF" --sdcard 512M || {
         echo "❌ Error: Failed to create AVD '$AVD_NAME'." >&2
         echo "   Maybe the device definition '$DEVICE_DEF' is invalid for this image?" >&2
         echo "   Check available devices: avdmanager list device" >&2
         exit 1
    }
    echo "✅ AVD '$AVD_NAME' created."
else
    echo "✅ AVD '$AVD_NAME' already exists. Will reuse."
fi


# --- Launch Emulator ---
echo "▶️ Launching existing/new emulator: '$AVD_NAME' (pointing to Bumble Netsim bridge on localhost:$BUMBLE_NETSIM_GRPC_PORT)..."
EMULATOR_LOG="emulator-$AVD_NAME.log" # Log file name updated for API 32 AVD
# Google Play images often need a writable system partition
# Explicitly point packet streamer to localhost:8554 where bridge is listening
nohup emulator -avd "$AVD_NAME" -no-snapshot-load -gpu auto -show-kernel -writable-system \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    > "$EMULATOR_LOG" 2>&1 &
EMULATOR_PID=$!
echo "   Emulator starting in background (PID: $EMULATOR_PID). Log: $EMULATOR_LOG"
echo -n "   Waiting for emulator to appear in ADB..."

# Wait for the emulator device to show up in adb
WAIT_ADB_TIMEOUT=90 # Increase timeout slightly for GPlay images
SECONDS=0
EMULATOR_ID="" # Reset variable
while [ $SECONDS -lt $WAIT_ADB_TIMEOUT ]; do
    # Find the *new* emulator ID
    CURRENT_EMU_ID=$(adb devices | grep 'emulator-' | head -n 1 | cut -f1)
    if [ -n "$CURRENT_EMU_ID" ]; then
        EMULATOR_ID="$CURRENT_EMU_ID"
        echo " Found ($EMULATOR_ID)!"
        break
    fi
    sleep 2
    SECONDS=$((SECONDS + 2))
    echo -n "."
done

if [ -z "$EMULATOR_ID" ]; then
    echo ""
    echo "❌ Error: Emulator did not appear in ADB within $WAIT_ADB_TIMEOUT seconds." >&2
    echo "   Check logs: $EMULATOR_LOG" >&2
    # Try to kill the process if it's still lingering
    kill $EMULATOR_PID 2>/dev/null || echo "   (Emulator process $EMULATOR_PID may have already exited)"
    exit 1
fi


# --- Wait for Boot Completion ---
echo -n "▶️ Waiting for Android system to fully boot (Google Play images can take longer)..."
BOOT_TIMEOUT=240 # Increase timeout significantly for GPlay images
SECONDS=0
while [ $SECONDS -lt $BOOT_TIMEOUT ]; do
    # Check if device is online first
    DEVICE_STATE=$(adb -s "$EMULATOR_ID" get-state 2>/dev/null)
    if [ "$DEVICE_STATE" != "device" ]; then
       echo -n "s($DEVICE_STATE)" # State not ready
       sleep 5
       SECONDS=$((SECONDS + 5))
       continue
    fi

    # Check boot completed property
    BOOT_COMPLETED=$(adb -s "$EMULATOR_ID" shell getprop sys.boot_completed 2>/dev/null | tr -d '
')
    if [ "$BOOT_COMPLETED" = "1" ]; then
        # Double check package manager is ready too for GPlay images
        PM_READY=$(adb -s "$EMULATOR_ID" shell pm get-install-location 2>/dev/null)
        if [[ "$PM_READY" == *"0"* || "$PM_READY" == *"1"* || "$PM_READY" == *"2"* ]]; then # Check if pm command gives valid output
            echo " Booted!"
            break
        else
            echo -n "p(pm not ready)" # Package Manager not ready
        fi
    else
         echo -n "b(booting)" # Boot not completed
    fi
    sleep 5
    SECONDS=$((SECONDS + 5))
done

if [ $SECONDS -ge $BOOT_TIMEOUT ]; then
    echo ""
    echo "❌ Error: Android system did not fully boot within $BOOT_TIMEOUT seconds." >&2
    echo "   Emulator might be stuck. Check logs ($EMULATOR_LOG) or try launching manually." >&2
    # Don't exit here, user might want to interact with stuck emulator
fi


# --- Final Instructions ---
echo "---"
echo "✅ Google Play Emulator '$AVD_NAME' (API $API_LEVEL) ($EMULATOR_ID) should be running."
echo "   Bluetooth should be using the Netsim backend at localhost:$BUMBLE_NETSIM_GRPC_PORT (intercepted by Bumble)."
echo "   Connect shell:   adb -s $EMULATOR_ID shell"
echo "   Install APK:     adb -s $EMULATOR_ID install /path/to/your.apk"
echo "   Stop emulator:   adb -s $EMULATOR_ID emu kill"
if [ -n "$EMULATOR_PID" ]; then # Only show PID if we launched it
    echo "   Kill Process:    kill $EMULATOR_PID"
fi
echo "   NOTE: Google Play Services may need updates inside the emulator."
echo "---"

exit 0

Points clés pour Mac M1 + émulateur + Bumble

Le niveau d'API compte : Plus récent ne veut pas toujours dire meilleur pour la compatibilité de l'émulateur, surtout avec des fonctions complexes comme le bridge Bluetooth. L'API 32 semblait plus stable pour cela que l'API 34 dans mes tests.
Endpoints explicites : Ne comptez pas sur -packet-streamer-endpoint default quand vous utilisez un bridge externe comme le mode contrôleur Netsim de Bumble. Pointez explicitement l'émulateur vers localhost:<port>, là où votre bridge écoute.
Bridge Netsim > socket QEMU : Le mode bridge android-netsim semble plus susceptible de fonctionner avec les émulateurs modernes que la méthode plus bas niveau -qemu -chardev socket, même si la méthode socket peut établir un lien TCP.
usb:0 vs VID:PID : Sur macOS/M1, l'identification des périphériques USB peut être capricieuse. Si spécifier le VID:PID exact échoue sans raison apparente, essayez d'utiliser l'index usb:0 (en supposant que ce soit le périphérique principal/prévu).
La persévérance paie : Il a fallu plusieurs tentatives, en combinant des indices venus de la documentation, de recherches web et de tests itératifs. Ne lâchez pas trop vite !

J'espère que ce partage de configuration précise et fonctionnelle fera gagner des heures de frustration à d'autres développeurs. Bon code (et bon bridging) !

Refonte de blog par IA : comment Claude Code a transformé mon site Gatsby

Sat, 12 Apr 2025 00:00:00 GMT

En tant que développeur qui passe la majeure partie de son temps côté backend, j'ai toujours eu du mal avec le design. Mon blog personnel était fonctionnel, mais il semblait coincé en 2010 : styles basiques, espacements incohérents, et une palette de couleurs que l'on pouvait généreusement qualifier de "minimale". Je voulais le refaire depuis des mois, mais l'idée de replonger dans le CSS et les systèmes de design me donnait des cauchemars.

Puis j'ai essayé Claude Code, l'assistant de programmation IA d'Anthropic, et ma perspective a complètement changé.

Le défi : mon blog triste et dépassé

Mon blog est construit avec Gatsby.js, et même si le contenu tenait la route, la présentation le desservait :

Espacement incohérent sur tout le site
Mauvais comportement responsive sur mobile
Une implémentation du mode sombre qui fonctionnait à peine
Une typographie qui faisait amateur, au mieux
Aucun système de couleurs ni langage de design cohérent

J'avais une idée vague de ce que je voulais : quelque chose de moderne, propre et professionnel, qui fasse briller mon contenu. Mais traduire cette vision en CSS réel ? C'est là que je bloque habituellement.

Entre en scène Claude Code : mon partenaire de design virtuel

J'entendais parler de Claude Code depuis un moment, mais j'étais sceptique sur l'aide réelle qu'une IA pouvait apporter au travail de design. Après tout, le design demande du goût et un oeil esthétique, pas seulement des connaissances techniques.

J'ai quand même décidé d'essayer, avec un prompt simple : "Please improve my styling by a ton." J'étais prêt à investir une heure de mon temps et les 15 dollars environ que cela coûterait en utilisation d'API pour voir ce qui était possible.

Ce qui s'est passé ensuite m'a sincèrement surpris.

Le processus de transformation

Au lieu de simplement suggérer quelques retouches CSS, Claude Code a abordé la refonte avec la rigueur d'un développeur professionnel :

Phase d'analyse : D'abord, il a examiné mes styles existants, l'architecture de mes composants et ma palette de couleurs pour comprendre avec quoi il travaillait.
Création d'un système de design : Plutôt que de faire des changements superficiels, il a construit un système de design complet comprenant :
- Une palette de couleurs professionnelle avec des variables sémantiques pour les modes clair et sombre
- Une échelle typographique modernisée, avec de vrais ajustements responsives
- Un système d'espacement cohérent basé sur une grille de 4 px
- Des ombres, rayons de bordure et transitions standardisés
Refonte des composants : Il a réécrit mes composants pour suivre les bonnes pratiques modernes :
- Création d'une mise en page responsive des articles, basée sur des cartes
- Implémentation d'un en-tête sticky avec effets de flou d'arrière-plan
- Design d'un sélecteur de thème élégant
- Ajout d'une navigation propre avec états actifs
Améliorations d'accessibilité : Claude Code ne s'est pas contenté de rendre les choses plus belles : il a rendu mon site plus accessible :
- Ajout d'une vraie prise en charge de la navigation au clavier
- Implémentation d'un lien d'évitement vers le contenu
- Garantie d'un contraste de couleurs suffisant
- Ajout de labels ARIA appropriés
Optimisation des performances : Le code a été optimisé pour les performances :
- Import sélectif des seuls composants Bootstrap nécessaires
- Optimisation de l'organisation du CSS
- Ajout d'animations accélérées matériellement

Les résultats renversants

La transformation était saisissante. En environ une heure d'allers-retours et pour seulement 15 dollars de coûts d'API Claude, mon blog est passé d'un air de projet secondaire de développeur à celui d'une publication conçue professionnellement. La refonte comprenait :

Un système de couleurs sophistiqué, avec une vraie prise en charge du mode sombre
Une belle typographie qui s'adapte parfaitement à tous les appareils
Des mises en page professionnelles en cartes pour les articles
Des animations et transitions fluides
Un en-tête sticky avec des effets façon verre
Un espacement cohérent sur tout le site

Pour mettre cela en perspective : engager un web designer professionnel pour ce niveau de travail coûterait probablement 1 000 à 2 000 dollars et prendrait des jours ou des semaines d'allers-retours. À la place, j'ai dépensé une heure de mon temps et 15 dollars en coûts d'API.

Mais ce qui m'a le plus impressionné, ce n'était pas seulement l'amélioration visuelle ou les économies : c'était la qualité du code. Claude Code n'a pas assemblé quelques hacks CSS ; il a créé un système de design complet et maintenable, sur lequel je peux facilement construire.

Ce que j'ai appris sur le design assisté par IA

Cette expérience a changé ma perspective sur ce que l'IA peut faire pour les développeurs :

L'IA excelle dans la pensée systémique : Claude Code ne s'est pas contenté de rendre les choses "plus jolies" : il a créé un système cohérent, avec des variables, des motifs constants et une organisation propre.
Elle comble les lacunes de connaissance : En tant que personne sans expertise profonde en CSS, Claude Code a rempli mes lacunes avec des bonnes pratiques modernes que je n'aurais pas pensé à implémenter.
Le code est de qualité production : Le framework de styles qu'il a créé n'est pas là pour faire joli : c'est du code maintenable et extensible, qui respecte les standards modernes.
Il a préservé mon contenu et ma structure : Claude Code a amélioré le design tout en conservant la structure centrale et le contenu de mon blog.

L'avenir de la collaboration développeur-IA

Mon expérience a mis en lumière quelque chose d'important : Claude Code ne remplace pas les développeurs, il augmente nos capacités. Il m'a aidé à dépasser mes limites personnelles en design frontend, tout en me laissant le contrôle de la direction générale.

Pour les développeurs qui sont plus forts dans certains domaines que dans d'autres (et n'est-ce pas notre cas à tous ?), les assistants IA comme Claude Code peuvent aider à combler les trous dans nos compétences.

Essayez-le vous-même

Si vous avez du mal avec le design ou avec tout autre aspect du développement, je vous recommande vivement d'essayer Claude Code. L'expérience a changé non seulement mon blog, mais aussi ma perception de ce qui est possible avec le développement assisté par IA.

Avez-vous essayé Claude Code ou des assistants de programmation IA similaires ? J'aimerais beaucoup lire vos expériences dans les commentaires ci-dessous.

Note : Ce blog lui-même a été redesigné avec Claude Code, donc ce que vous voyez maintenant est le résultat du processus que je viens de décrire. La transformation depuis mon ancien design jusqu'à celui-ci a pris environ une heure de prompts et d'itérations, et a coûté environ 15 dollars d'utilisation de l'API Claude. Quand on considère les coûts habituels du design, c'est une proposition de valeur incroyable.

Appairage BLE de la Huawei Watch D2 : protocole et verrouillage fournisseur

Fri, 11 Apr 2025 00:00:00 GMT

TL;DR : La Huawei Watch D2 n'utilise pas l'appairage BLE standard. Elle exige à la place une poignée de main propriétaire en 11 étapes, avec caractéristiques GATT sur mesure, dérivation de clé HMAC-SHA256 depuis un code QR, et chiffrement au niveau applicatif. C'est du verrouillage fournisseur par conception : cela vous force à passer par l'app Health de Huawei. La bonne nouvelle : la communauté l'a rétro-ingénierée. Gadgetbridge prend maintenant en charge la Watch D2, et des implémentations open source comme huawei-lpv2 existent. Le DMA européen commence lui aussi à pousser en sens inverse.

Je m'attendais à un appairage Bluetooth standard. Connexion, association, échange de données : l'ordinaire. À la place, j'ai trouvé une poignée de main cryptographique propriétaire qui a demandé des semaines de rétro-ingénierie.

C'est arrivé pendant la construction de D2Explorer, mon projet pour connecter la Huawei Watch D2 à Linux et macOS sans l'app Health de Huawei. Après avoir démêlé les problèmes d'agent d'appairage de BlueZ et migré vers la bibliothèque multiplateforme SimpleBLE, je pensais que le plus dur était derrière moi. Le plus dur n'avait pas commencé.

Ce à quoi on s'attend : l'appairage BLE standard

Voici comment l'appairage Bluetooth LE est censé fonctionner :

Scanner l'appareil par son nom annoncé (par exemple, "HUAWEI WATCH D2-CA0").
Se connecter avec peripheral.connect().
Le système d'exploitation gère l'appairage/l'association : demande de PIN, Just Works, ou ce que le niveau de sécurité exige.
Une fois l'association établie, interagir avec les services GATT standard ou personnalisés.

Le système gère la sécurité. Votre application se concentre sur les données. Simple.

Ce qui se passe vraiment : une poignée de main propriétaire en 11 étapes

Ce que la Watch D2 exige réellement est tout autre. La connexion BLE de base n'est que la porte. Derrière elle se trouve un protocole d'authentification applicatif sur mesure que Huawei a construit par-dessus le BLE standard : ce que la communauté appelle Huawei Link Protocol v2 [1].

Les mécanismes d'appairage BLE standard sont complètement contournés. Pour vous authentifier et accéder à la moindre donnée utile, vous devez parcourir cette séquence via des caractéristiques GATT personnalisées :

Connect -- établir le lien BLE de base.
Enable Notifications -- s'abonner immédiatement aux notifications sur la caractéristique 0000fe02-.... Le timing est critique : ratez la fenêtre et la montre vous déconnecte.
GetLinkParams -- envoyer immédiatement une commande personnalisée (Service ID 0x0001, Command ID 0x0001) à la caractéristique d'écriture 0000fe01-....
Receive Server Nonce -- attendre une notification contenant le défi aléatoire de la montre.
Derive Secret Key -- générer un nonce client. Combiner le nonce serveur, le nonce client, et la valeur numérique du code QR affiché par la montre. Exécuter HMAC-SHA256 (en utilisant les octets de la valeur du code QR comme clé) pour dériver une secretKey_ partagée.
AuthRequest -- renvoyer à la montre le nonce client et un digest HMAC (en utilisant la secretKey_ dérivée) (Service 0x0001, Command 0x0002).
Verify Server Token -- recevoir le jeton d'authentification de la montre. Le vérifier avec la secretKey_ et les nonces échangés.
SetTime -- envoyer l'heure actuelle et le décalage de fuseau horaire, chiffrés avec la secretKey_ (Service 0x0002, Command 0x0003).
QrToken -- renvoyer la valeur du code QR, chiffrée avec la secretKey_ (Service 0x0001, Command 0x0004).
AuthResult -- envoyer une confirmation finale, chiffrée avec la secretKey_ (Service 0x0001, Command 0x0005).
Done -- c'est seulement maintenant que la connexion est authentifiée.

Formats de messages TLV personnalisés. Contrôles CRC. IDs de service et de commande. Chiffrement applicatif. Timing sensible à la milliseconde. Tout cela se passe au-dessus de la pile BLE, invisible pour les outils Bluetooth standard.

Le code QR sur l'écran de la montre est le secret partagé. Sans lui, vous ne pouvez pas dériver la clé. Sans la clé, vous ne pouvez pas vous authentifier. Sans authentification, la montre ne vous donne rien.

Pourquoi Huawei fait cela

Huawei pourrait présenter cela comme une sécurité renforcée. L'effet pratique est le verrouillage fournisseur.

Barrière d'entrée élevée -- le protocole n'est pas documenté. Le réimplémenter demande de rétro-ingénierer l'app Huawei Health (plus de 13 000 classes, plus de 64 000 méthodes [2]) ou d'analyser le trafic BLE. Cela décourage activement les applications tierces.
Aucune interopérabilité -- les applications de fitness standard ne peuvent pas se connecter. La montre ne termine sa poignée de main qu'avec un logiciel qui connaît les étapes propriétaires, principalement l'app Health de Huawei.
Contrôle de l'écosystème -- les utilisateurs sont forcés d'entrer dans Huawei Health et ses services cloud. Changer d'appareil ou de plateforme plus tard signifie perdre l'historique de vos données de santé.
Choix utilisateur réduit -- vous voulez utiliser une app open source ? Vous voulez plus de contrôle sur la confidentialité de vos données de santé ? Dommage, à moins que quelqu'un ne rétro-ingénie d'abord le protocole.

Et voici le point important : ce n'est pas propre à Huawei. Le projet de recherche WatchWitch [3] documente comment tous les grands fournisseurs, Apple, Samsung, Xiaomi, utilisent des protocoles BLE propriétaires pour imposer le verrouillage d'écosystème. L'Apple Watch est "incredibly tightly coupled with Apple's iPhone and iCloud ecosystem, using proprietary protocols that are unavailable to third parties." C'est un problème systémique de l'industrie.

Mais l'implémentation de Huawei est particulièrement agressive. BLE permet des services personnalisés, bien sûr. Mais remplacer le mécanisme d'authentification fondamental par un gardien propriétaire, c'est un autre jeu.

L'ironie de la sécurité

La défense évidente est : "nous faisons cela pour la sécurité." Examinons-la.

La recherche BlueDoor de l'université Tsinghua [4] a testé 16 appareils BLE, dont le Honor Band 3 (même écosystème Huawei), et a réussi un appairage silencieux sans autorisation utilisateur sur la plupart d'entre eux. Le protocole propriétaire ne l'a pas empêché.

Pendant ce temps, le protocole lui-même a été rétro-ingénieré plusieurs fois : par la communauté Gadgetbridge, par le projet huawei-lpv2, par les chercheurs qui ont présenté leurs travaux à Easterhegg 2019 [2], et par moi pour D2Explorer. De la sécurité par l'obscurité, avec une date d'expiration.

La dérivation de clé HMAC-SHA256 depuis le code QR est en fait une cryptographie correcte. Mais ce n'est pas le sujet. On pourrait obtenir les mêmes propriétés de sécurité avec BLE Secure Connections standard et une méthode d'appairage hors bande (comme NFC ou un code QR), sans exclure toutes les applications tierces au passage.

La communauté riposte

La communauté n'a pas accepté cela en silence.

Gadgetbridge

Gadgetbridge, l'application Android open source pour objets connectés, prend maintenant en charge la Huawei Watch D2 [5]. Vous pouvez appairer votre montre sans l'app Health de Huawei. Il a fallu un effort considérable de rétro-ingénierie (voir la PR #2462 [6]), et il reste des limites : la fonctionnalité ECG est désactivée lorsque la montre est appairée avec Gadgetbridge [7]. Mais cela fonctionne.

L'implémentation d'authentification dans Gadgetbridge gère la version d'auth 3, calcule la clé d'association depuis le message d'appairage (service 0x01, commande 0x0e) et l'utilise pour le déchiffrement. Un identifiant de compte Huawei à 17 chiffres est nécessaire pour la négociation de la clé d'authentification.

huawei-lpv2

Le projet huawei-lpv2 fournit une implémentation pure Python du Huawei Link Protocol v2 [8]. Il est maintenu, possède plusieurs forks, et sert de référence à quiconque construit des intégrations avec des wearables Huawei en dehors de l'écosystème officiel.

D2Explorer

Mon propre projet D2Explorer a pris une autre voie : construire une implémentation C++ avec SimpleBLE qui fonctionne sous Linux et macOS. Le travail a impliqué :

Implémenter la sérialisation/désérialisation TLV (HuaweiProtocol).
Construire des messages précis (ProtocolMessageBuilder).
Réussir les étapes cryptographiques : génération de nonce, HMAC-SHA256, chiffrement XOR (CryptoOperations, CryptoUtils).
Gérer des transitions d'état et un timing stricts (HuaweiPairingProtocol, ProtocolStateManager).
Déboguer des échecs causés par des décalages de timing à l'échelle de la milliseconde et des erreurs crypto subtiles.

D2Explorer existe parce que le protocole de Huawei l'a rendu nécessaire. C'est le contournement requis pour une fonctionnalité de base hors du jardin clos.

AsteroidOS

AsteroidOS 2.0 a été lancé en février 2026 comme mise à jour majeure de l'OS de smartwatch open source basé sur Linux [9]. Il prend maintenant en charge environ 30 appareils, dont la Huawei Watch et la Huawei Watch 2, avec des fonctionnalités comme l'affichage always-on et Tilt-to-Wake. Une vraie alternative open source au firmware de Huawei.

La marée réglementaire

L'UE ne se contente pas de regarder. Le Digital Markets Act (DMA) commence à forcer le changement [10].

En décembre 2025, Apple a publié iOS 26.3 avec un appairage façon AirPods pour les appareils tiers, y compris les montres connectées Huawei, précisément pour se conformer aux exigences du DMA [11]. La synchronisation en arrière-plan entre les montres Huawei et les iPhones est déjà opérationnelle en Europe.

Le DMA impose aux gatekeepers de fournir l'interopérabilité pour les appareils connectés. Cela cible directement le type de verrouillage BLE propriétaire que Huawei (et Apple, et tous les autres) pratiquent depuis des années. Le déploiement complet de ces fonctionnalités d'interopérabilité est attendu tout au long de 2026.

C'est important. Pour la première fois, une pression réglementaire pousse à standardiser ce que les fournisseurs ont délibérément gardé propriétaire. La communauté technique peut rétro-ingénierer les protocoles un par un, mais la régulation peut changer la structure d'incitation de toute l'industrie.

Ce que cela signifie

Le protocole d'appairage de la Huawei Watch D2 est une étude de cas sur la manière dont des protocoles personnalisés sur des transports standard peuvent imposer un verrouillage fournisseur. Les couches de cryptographie propriétaire, les formats de message sur mesure et les poignées de main sensibles au timing existent non pas parce que le BLE standard ne sait pas gérer l'authentification, il le sait, mais parce que les protocoles propriétaires gardent les utilisateurs à l'intérieur de l'écosystème.

Le tableau change pourtant. Gadgetbridge vous donne une alternative dès maintenant. Le DMA européen force l'interopérabilité au niveau réglementaire. Et les projets open source comme huawei-lpv2, D2Explorer et AsteroidOS prouvent que la communauté rétro-ingénierera ce que les fournisseurs essaient de verrouiller.

Construire D2Explorer relevait moins du Bluetooth que de l'enquête cryptographique. Cela souligne quelque chose qui ne devrait pas avoir besoin d'être souligné : vous devriez pouvoir accéder à vos propres données de santé avec le logiciel de votre choix.

Références

1. huawei-lpv2: Pure Python implementation of Huawei BLE Link Protocol v2 -- Implémentation de référence open source du protocole.
2. All Your Fitness Data Belongs to You: Reverse Engineering the Huawei Health Android App -- Conférence Easterhegg 2019 documentant l'effort de rétro-ingénierie. Slides (PDF).
3. WatchWitch: Academic Research on Smartwatch Interoperability -- Documente comment tous les grands fournisseurs utilisent des protocoles propriétaires pour verrouiller leurs écosystèmes.
4. BlueDoor: Breaking the Secure Information Flow via BLE Vulnerability (Tsinghua University) -- A trouvé des vulnérabilités d'appairage silencieux dans 16 appareils BLE, dont le Honor Band 3.
5. Gadgetbridge: Huawei/Honor Device Support -- Page officielle de prise en charge des wearables Huawei et Honor.
6. Gadgetbridge PR #2462: Initial Huawei/Honor Support -- La pull request qui a ajouté la prise en charge des appareils Huawei à Gadgetbridge.
7. Gadgetbridge Issue #4918: ECG Disabled with Gadgetbridge -- Limite connue lors de l'utilisation de Gadgetbridge à la place de Huawei Health.
8. Gadgetbridge: Huawei/Honor Pairing Guide -- Instructions pas à pas pour appairer les appareils Huawei.
9. AsteroidOS 2.0 Release -- OS de smartwatch open source prenant maintenant en charge environ 30 appareils, dont les montres Huawei.
10. EU Digital Markets Act: Interoperability Requirements -- Dispositions du DMA imposant l'interopérabilité des appareils connectés.
11. iOS 26.3 DMA Features: Third-Party Smartwatch Pairing -- Mise en conformité d'Apple avec les obligations européennes d'interopérabilité pour les wearables.

Correctif d'appairage BlueZ : agent Python externe et polling D-Bus

Tue, 08 Apr 2025 00:00:00 GMT

TL;DR : Si vous obtenez org.bluez.Error.AuthenticationFailed avec un agent d'appairage C++/sd-bus personnalisé sur BlueZ 5.66+, le problème vient probablement de l'enregistrement de votre agent interne. Lancez un agent Python externe (simple-agent.py) comme processus séparé, et implémentez un polling des propriétés D-Bus au lieu de vous fier aux signaux PropertiesChanged. Détails et code ci-dessous.

J'ai passé deux jours à fixer org.bluez.Error.AuthenticationFailed avant de comprendre ce qui se passait.

L'agent d'appairage était enregistré. Les appels D-Bus avaient l'air corrects. busctl confirmait que tout était en place -- et BlueZ continuait simplement à dire non. C'était pendant le travail sur D2Explorer -- un outil pour appairer la Huawei Watch D2 sous Linux -- et l'erreur d'appairage bloquait tout.

Voici ce qui s'est réellement passé, et comment nous l'avons corrigé.

Le plan : un agent d'appairage C++ interne

L'idée était propre et autonome. Une seule application C++ qui gère tout le processus d'appairage avec sd-bus (les bindings D-Bus C/C++) :

Se connecter au D-Bus système.
Trouver l'adaptateur Bluetooth (org.bluez.Adapter1).
Implémenter une classe C++ exposant l'interface org.bluez.Agent1.
Enregistrer l'agent auprès de org.bluez.AgentManager1 via RegisterAgent et RequestDefaultAgent. Nous avons commencé avec la capacité DisplayYesNo, puis nous avons simplifié vers NoInputNoOutput.
Découvrir l'appareil cible (org.bluez.Device1).
Appeler Pair() sur l'interface D-Bus de l'appareil.
L'agent interne gère automatiquement les callbacks (RequestConfirmation, RequestAuthorization) -- aucune interaction utilisateur nécessaire.
Marquer l'appareil comme approuvé, établir une connexion GATT, terminé.

Un binaire, aucune dépendance externe. C'était le plan.

Le mur : `org.bluez.Error.AuthenticationFailed`

Tout fonctionnait jusqu'à l'étape 6. Adaptateur trouvé, agent enregistré (D-Bus le confirmait), appareil découvert. Mais au moment où nous appelions Device1.Pair() via sd_bus_call_method -- échec instantané :

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method threw exception: Failed to call method 'Pair':
    Input/output error - D-Bus error: org.bluez.Error.AuthenticationFailed (Authentication Failed)

Nous avons tout essayé. Différentes capacités d'agent. Vérification de la configuration de la vtable sd-bus. Confirmation que les implémentations des méthodes de l'agent renvoyaient bien un succès rapidement. Utilisation de busctl et gdbus pour surveiller le trafic D-Bus -- les appels d'enregistrement semblaient corrects. L'appel Pair() continuait simplement à échouer.

Impasse.

La percée : un agent Python externe

Pour isoler le problème, nous avons retiré l'agent C++ interne de l'équation. Nous avons lancé le simple-agent.py standard de BlueZ comme processus séparé avant de lancer notre application C++ (désormais privée de son propre enregistrement d'agent) :

# Terminal 1: Run the external agent
sudo python simple-agent.py NoInputNoOutput

# Terminal 2: Run our C++ app (no internal agent)
sudo ./build/huawei_pair_app <MAC> <QR_VALUE>

Le résultat :

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method succeeded  <--- SUCCESS!

Régulier. À chaque fois. L'erreur AuthenticationFailed a complètement disparu.

Cela prouvait que le problème ne venait pas de Pair() lui-même, ni de l'appareil, ni de la capacité d'appairage de BlueZ. Il concernait précisément la manière dont notre application C++, via sd-bus, s'enregistrait et interagissait comme agent d'appairage. La même opération logique exacte -- enregistrer un agent NoInputNoOutput et appeler Pair() -- fonctionnait parfaitement quand l'agent tournait dans un processus Python séparé.

Ça a marché.

Pourquoi l'agent interne échouait-il ?

Quand je suis tombé dessus, je n'avais que des hypothèses. Depuis, j'ai trouvé des preuves documentées montrant que c'est un problème plus large -- pas seulement notre code.

Régression BlueZ 5.70+

L'issue BlueZ GitHub #605 documente des cas où des appareils s'appairent correctement sur BlueZ 5.50 mais échouent sur des versions plus récentes avec auth failed with status 0x05. Les journaux HCI montrent Status: PIN or Key Missing (0x06) malgré des clés de liaison stockées. Le contournement ? Lancer l'ancien script bluez-simple-agent.py. Ça vous rappelle quelque chose ?

La disponibilité de l'agent est la cause racine

L'issue Bleak #1434 rend cela encore plus clair : l'appairage ne fonctionne que lorsque bluetoothctl ou GNOME Bluetooth tourne, parce que ces applications enregistrent l'agent d'authentification nécessaire. Sans agent actif et fonctionnant correctement, BlueZ renvoie en interne No agent available for request type 2 -- ce qui remonte sous forme de AuthenticationFailed.

L'idée clé : il ne suffit pas d'enregistrer un agent. L'agent doit répondre aux callbacks de BlueZ d'une manière que bluetoothd considère valide. Et quelque chose dans la façon dont sd-bus gère cela au sein du même processus que celui qui initie l'appairage ne satisfait pas les versions récentes de BlueZ.

Ce n'est peut-être même pas BlueZ

Le bug Red Hat #1905671 a révélé que certaines erreurs AuthenticationFailed sont liées au noyau, pas à BlueZ. Le noyau 5.9 avait des problèmes d'appairage que 5.8.18 et 5.10+ n'avaient pas. Le commentaire du mainteneur vaut la peine d'être cité : « Bluetooth is complex, it could be firmware, kernel, bluez, controller, end device or a combination of them all. »

Incompatibilité de capacité d'agent

L'issue BlueZ #650 documente un autre angle : certains appareils (notamment iOS) échouent lors d'un appairage avec des agents NoInputNoOutput, parce qu'ils rétrogradent Secure Connections vers l'appairage Legacy, provoquant ensuite des erreurs Insufficient Authentication (0x05) lors de l'accès aux attributs. C'est un problème de négociation Security Manager Protocol (SMP), pas un problème d'enregistrement d'agent -- mais il produit le même message d'erreur.

Les coupables probables dans notre cas

Au vu des éléments, les explications les plus probables de l'échec de l'agent interne sd-bus sont :

Timing -- l'enregistrement sd-bus ou la gestion des méthodes dans notre boucle d'événements ne répondait pas exactement dans la fenêtre attendue par bluetoothd.
Subtilités sd-bus vs python-dbus -- différences dans la façon dont ces bibliothèques interagissent avec le démon D-Bus ou gèrent la durée de vie des objets.
Exigences plus strictes dans BlueZ 5.66+ -- séquences internes modifiées pour l'interaction avec l'agent, que sd-bus, utilisé dans la même application que celle qui initie l'appairage, ne satisfait pas.

Le second mur : les signaux D-Bus ne sont pas fiables

Passer AuthenticationFailed était une grosse victoire, mais ce n'était pas la fin. Avec l'agent externe en place, Pair() réussissait -- mais nous ne pouvions pas détecter de façon fiable quand il se terminait.

Nous nous reposions sur les signaux D-Bus PropertiesChanged (via sd-bus) pour savoir quand Paired, Trusted, Connected et ServicesResolved devenaient true. Parfois les signaux arrivaient. Parfois ils arrivaient en retard. Parfois ils n'arrivaient pas du tout.

Nous avons donc implémenté un polling actif -- un fallback qui interroge directement les valeurs des propriétés lorsque les signaux ne se présentent pas :

bool BluetoothDevice::isPaired() {
    bool cachedValue = mockPaired_.load(); // Check signal-updated cache
    if (cachedValue) return true;

    // Signal didn't fire? Poll D-Bus directly.
    Logger::debug("[Polling] Polling Paired property via D-Bus...");
    bool polledValue = false;
    adapter_.getObjectProperty<bool>(
        devicePath_, "org.bluez.Device1", "Paired", polledValue
    );
    if (polledValue) mockPaired_.store(true); // Update cache
    return polledValue;
}

Chaque méthode de transition d'état (isPaired(), isTrusted(), isConnected(), areServicesResolved()) suit le même schéma : vérifier d'abord le booléen atomique en cache (mis à jour par le gestionnaire de signal s'il fonctionne), puis retomber sur un appel D-Bus direct Get pour la propriété.

Pas élégant. Mais nécessaire.

Ça a marché.

Le correctif complet

Voici la recette consolidée. Si vous construisez un appairage Bluetooth automatisé sous Linux avec BlueZ 5.66+ et que vous tombez sur AuthenticationFailed :

Étape 1 : récupérer simple-agent.py

Prenez-le dans l'arbre source de BlueZ.

Étape 2 : lancer l'agent externe

sudo python simple-agent.py NoInputNoOutput

Gardez-le actif dans un terminal séparé (ou comme service en arrière-plan).

Étape 3 : retirer l'agent interne de votre application

Supprimez tous les appels RegisterAgent / RequestDefaultAgent de votre application C++. Laissez l'agent Python externe gérer les callbacks d'authentification.

Étape 4 : ajouter le polling des propriétés D-Bus

Ne vous fiez pas uniquement aux signaux PropertiesChanged. Pour chaque propriété critique (Paired, Trusted, Connected, ServicesResolved), implémentez le schéma cache-puis-polling montré ci-dessus. Interrogez périodiquement depuis votre boucle principale.

Étape 5 : vérifier

Confirmez que l'agent externe tourne (sudo python simple-agent.py NoInputNoOutput).
Lancez votre application. Pair() devrait réussir.
Surveillez les logs de polling -- vous devriez voir des requêtes de propriétés D-Bus pour les transitions d'état.
Si Pair() échoue encore, vérifiez votre version de BlueZ (bluetoothd --version) et votre version de noyau -- le problème est peut-être plus profond.

Ce que cela vous coûte

Je ne vais pas prétendre que c'est une solution propre. Ça ne l'est pas :

Dépendance externe -- votre application a maintenant besoin d'un processus Python séparé en cours d'exécution.
Plus de complexité -- logique de polling dans la boucle principale, en plus des gestionnaires de signaux.
Moins autonome -- le rêve d'un seul binaire a disparu.

Mais ça marche. De façon fiable. Et quand vous avez fixé AuthenticationFailed pendant deux jours, « ça marche » est ce qui compte.

Références

1. BlueZ GitHub Issue #55: Device characteristics and pairing timing -- Échecs d'appairage intermittents liés au timing de l'agent.
2. Bluetooth Auto Pairing with NoInputNoOutput Agent Issues -- Discussion de forum sur les défis de l'appairage headless.
3. BlueZ Source: test/simple-agent -- L'agent Python standard.
4. BlueZ GitHub Issue #605: Pairing regression in 5.70+ -- Échecs documentés avec les versions récentes de BlueZ.
5. Bleak Issue #1434: Pairing requires active agent -- Preuve que la disponibilité de l'agent est la cause racine.
6. Red Hat Bug #1905671: Kernel-related pairing failures -- Ce n'est pas toujours BlueZ -- parfois c'est le noyau.
7. BlueZ GitHub Issue #650: Agent capability mismatch -- Échecs de négociation SMP avec NoInputNoOutput.
8. BlueZ Agent API Documentation -- Référence officielle de l'interface agent.
9. Kynetics: Pairing Agents in the BlueZ Stack -- Analyse technique détaillée de l'enregistrement des agents.

Articles liés

Appairage BLE de la Huawei Watch D2 : protocole et verrouillage fournisseur -- le projet qui a déclenché cette enquête. La Watch D2 exige une poignée de main propriétaire au niveau applicatif, par-dessus l'appairage BLE standard, ce qui explique pourquoi nous avions besoin que l'appairage automatisé fonctionne dès le départ.
Corriger le Bluetooth de l'émulateur Android sur Mac M1 avec Bumble et API 32 -- une autre bataille d'intégration Bluetooth, cette fois pour faire passer la radio physique d'un Mac dans l'émulateur Android.

Guide dev : mises à jour des classes et namespaces dans Shopware 6.5/6.6

Sat, 30 Nov 2024 00:00:00 GMT

Shopware 6.5 et 6.6 ont introduit plusieurs changements importants dans les classes, les namespaces, les attributs data et les mécanismes de sécurité dont les développeurs doivent tenir compte lorsqu’ils mettent à jour ou maintiennent leurs projets Shopware. Cet article propose un aperçu concis mais complet de ces changements, avec quelques observations sur leur impact et sur la manière d’adapter votre code.

Introduction

À mesure que Shopware évolue, les mises à jour apportent souvent des améliorations, des optimisations et de nouvelles fonctionnalités. Elles peuvent toutefois aussi introduire des changements qui affectent les bases de code existantes. Comprendre ces changements est essentiel pour assurer une transition fluide et exploiter efficacement les nouvelles capacités.

Cet article se concentre sur les points suivants :

Migration du namespace Elasticsearch
Mises à jour de la gestion des chemins média
Changements de méthode dans AvailableCombinationLoader
Mise à niveau du framework Symfony vers la version 6
Mises à jour de la gestion du stock
Mise à niveau de Bootstrap dans le Storefront
Changements d’attribut data pour l’Offcanvas Cart
Changements de protection CSRF
Améliorations du Rule Builder

Entrons dans le détail de chacun de ces changements.

1. Migration du namespace Elasticsearch

Aperçu du changement

Namespace précédent : ONGR\ElasticsearchDSL
Nouveau namespace : OpenSearchDSL

Impact

Toutes les classes et méthodes qui interagissent avec Elasticsearch doivent mettre à jour leurs namespaces afin de refléter la migration de ONGR\ElasticsearchDSL vers OpenSearchDSL.

Action requise

Mettez à jour les instructions d’import et les références dans votre code pour utiliser le nouveau namespace.

Exemple

// Before
use ONGR\ElasticsearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

// After
use OpenSearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

Observations

Ce changement s’aligne sur le mouvement plus large de l’industrie vers OpenSearch, un fork communautaire d’Elasticsearch. Passer au nouveau namespace garantit la compatibilité avec les développements et le support à venir.

2. Gestion des chemins média

Aperçu du changement

Les chemins média sont désormais stockés directement en base de données au lieu d’être générés dynamiquement.

Impact

Les classes et services qui s’appuyaient auparavant sur la génération dynamique des chemins doivent lire les chemins média depuis la base de données.

Action requise

Adaptez votre code pour utiliser la méthode getPath() de MediaEntity.

Exemple

// Before (dynamic path generation)
$mediaPath = $mediaService->getPath($mediaId);

// After (database-stored path)
$mediaPath = $mediaEntity->getPath();

Observations

Stocker les chemins média en base de données améliore les performances en réduisant le coût de calcul. Cela apporte aussi plus de cohérence et de fiabilité dans la gestion des médias.

3. Mise à jour de méthode dans `AvailableCombinationLoader`

Aperçu du changement

La méthode load() dans AbstractAvailableCombinationLoader a été remplacée par loadCombinations().

Impact

Toute classe personnalisée qui étend AbstractAvailableCombinationLoader doit implémenter la nouvelle méthode loadCombinations() au lieu de l’ancienne méthode load().

Action requise

Renommez ou refactorez vos implémentations de méthode pour les aligner sur le nouveau nom et la nouvelle signature.

Exemple

// Before
$combinations = $combinationLoader->load($productId);

// After
$combinations = $combinationLoader->loadCombinations($productId);

Observations

Ce changement renforce la clarté avec un nom de méthode plus descriptif. Il peut aussi impliquer des paramètres ou des types de retour supplémentaires ; il est donc essentiel de relire la signature de la méthode.

4. Mise à niveau du framework Symfony vers la version 6

Aperçu du changement

Shopware a mis à niveau ses composants Symfony vers la version 6.

Impact

Cette mise à niveau introduit quelques breaking changes liés à des fonctionnalités dépréciées et à des changements de signatures de méthodes. Le code personnalisé qui dépend d’anciennes fonctionnalités Symfony peut casser ou produire des avertissements.

Action requise

Relisez votre code pour identifier les fonctionnalités Symfony dépréciées et mettez-les à jour afin qu’elles soient compatibles avec Symfony 6.

Observations

Rester à jour avec la dernière version de Symfony apporte de meilleures performances, une meilleure sécurité et l’accès à de nouvelles fonctionnalités. Cela demande toutefois une revue attentive du code et des tests pour garantir la compatibilité.

5. Mises à jour de la gestion du stock

Aperçu du changement

Une nouvelle Stock API a été introduite, disponible derrière le feature flag STOCK_HANDLING.

Impact

Les classes et services liés à la gestion du stock peuvent devoir s’adapter à la nouvelle structure de l’API, surtout s’ils interagissent directement avec les données de stock.

Action requise

Utilisez les nouvelles méthodes de gestion du stock fournies par l’API et assurez-vous que toute logique liée au stock s’aligne sur la structure mise à jour.

Exemple

// Before
$stock = $productEntity->getStock();

// After
$stock = $stockService->getStock($productId);

Observations

La nouvelle Stock API fournit une manière plus robuste et plus flexible de gérer le stock, ce qui peut simplifier les personnalisations et les intégrations avec des systèmes externes.

6. Mise à niveau de Bootstrap dans le Storefront

Aperçu du changement

Le Storefront est passé de Bootstrap 4 à Bootstrap 5, et jQuery a été retiré comme dépendance.

Impact

Le code JavaScript personnalisé et les templates qui s’appuient sur jQuery ou sur des composants Bootstrap 4 doivent être refactorés pour s’aligner sur Bootstrap 5 et utiliser du JavaScript natif lorsque c’est nécessaire.

Action requise

Remplacez l’usage de jQuery par du JavaScript natif ou par les utilitaires Bootstrap 5.
Mettez à jour les classes et composants Bootstrap pour correspondre au nommage et à la structure de Bootstrap 5.

Observations

Bootstrap 5 apporte de meilleures performances, moins de dépendances et des composants modernisés. La mise à jour peut prendre du temps, mais elle offre des bénéfices durables en maintenabilité et en expérience utilisateur.

7. Changements d’attribut data pour l’Offcanvas Cart (Shopware 6.6)

Aperçu du changement

Dans Shopware 6.6, un changement discret mais important a été introduit dans l’attribut data utilisé pour déclencher la fonctionnalité d’offcanvas cart.

Attribut data précédent : data-offcanvas-cart
Nouvel attribut data : data-off-canvas-cart

Impact

Les templates ou thèmes personnalisés qui utilisent l’attribut data-offcanvas-cart sans traits d’union peuvent constater que l’offcanvas cart ne fonctionne plus comme prévu, car le listener JavaScript de Shopware 6.6 cherche la version avec traits d’union.

Action requise

Mettez à jour l’attribut data-offcanvas-cart dans vos templates vers data-off-canvas-cart.

Exemple

<!-- Before -->
<div class="header-cart" data-offcanvas-cart="true">
    <!-- Cart content -->
</div>

<!-- After -->
<div class="header-cart" data-off-canvas-cart="true">
    <!-- Cart content -->
</div>

Observations

Ce changement est mal documenté dans les notes de version officielles de Shopware 6.6, mais il est crucial pour le bon fonctionnement de l’offcanvas cart. Le JavaScript chargé d’initialiser la fonctionnalité du panier s’appuie sur l’attribut data-off-canvas-cart, et tout écart peut empêcher le panier de fonctionner.

Notes supplémentaires

La cohérence est essentielle : assurez-vous que toutes les occurrences de l’attribut offcanvas cart sont mises à jour.
Testez soigneusement : après le changement, testez la fonctionnalité du panier pour confirmer qu’elle se comporte comme attendu.
Cherchez les changements similaires : d’autres attributs data ou listeners d’événements ont peut-être subi des mises à jour comparables ; relisez vos templates personnalisés en conséquence.

8. Changements de protection CSRF

Aperçu du changement

Shopware 6.5 et les versions ultérieures ont supprimé la gestion explicite des tokens CSRF dans les templates, au profit d’une stratégie de cookies SameSite pour la protection CSRF.

Impact

Les templates et formulaires qui incluaient auparavant des tokens CSRF avec la fonction sw_csrf rencontreront des erreurs, car cette fonction n’existe plus.

Action requise

Supprimez les fonctions de token CSRF : éliminez l’usage de {{ sw_csrf('route_name') }} dans vos templates.
Appuyez-vous sur les cookies SameSite : faites confiance à la stratégie SameSite intégrée pour la protection CSRF, qui ne requiert pas de tokens explicites dans les formulaires.
Ajustez les attributs de formulaire : assurez-vous que les formulaires et les requêtes AJAX sont correctement configurés pour fonctionner avec le nouveau mécanisme de protection CSRF.

Exemple

<!-- Before -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    {{ sw_csrf('frontend.checkout.line-item.add') }}
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

<!-- After -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

Observations

Résolution de l’erreur : supprimer la fonction sw_csrf résout l’erreur "Unknown 'sw_csrf' function".
Maintien de la sécurité : la stratégie de cookies SameSite continue de protéger contre les attaques CSRF sans tokens supplémentaires.
Templates simplifiés : les formulaires deviennent plus propres et légèrement plus simples sans tokens CSRF.

Notes supplémentaires

Les tests sont essentiels : après ces changements, testez soigneusement les soumissions de formulaires pour vérifier qu’elles fonctionnent correctement.
Comprenez le nouveau mécanisme : familiarisez-vous avec le fonctionnement de la stratégie SameSite pour conserver une application sécurisée.
Mettez la documentation à jour : assurez-vous que toute documentation interne reflète ce changement afin d’éviter de futures confusions.

9. Gérer les problèmes avec l’Offcanvas Cart

Aperçu du scénario

Après avoir mis à jour les templates et supprimé la fonction sw_csrf, les développeurs peuvent encore rencontrer des problèmes : cliquer sur le bouton "Add to Cart" ouvre l’offcanvas cart, mais celui-ci apparaît vide.

Cause racine

L’offcanvas cart peut ne pas afficher les articles ajoutés à cause de paramètres manquants ou incorrects dans la soumission du formulaire, en particulier l’absence du champ d’entrée redirectTo.

Action requise

Ajoutez le paramètre redirectTo : incluez dans vos formulaires d’ajout au panier un champ caché nommé redirectTo avec la valeur frontend.cart.offcanvas.
Assurez-vous que les attributs data sont corrects : vérifiez que tous les attributs data nécessaires sont présents et correctement nommés.

Exemple

<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <input type="hidden" name="redirectTo" value="frontend.cart.offcanvas"/>
    <input type="hidden" name="lineItems[{{ product.id }}][id]" value="{{ product.id }}">
    <!-- Other form fields -->
    <button type="submit">Add to Cart</button>
</form>

Observations

Restauration de la fonctionnalité : ajouter le paramètre redirectTo indique à Shopware de charger l’offcanvas cart lors de l’ajout d’un article, ce qui garantit que le panier s’affiche correctement.
Attention au détail : de petites omissions, comme des champs d’entrée manquants, peuvent provoquer des problèmes fonctionnels importants ; cela rappelle l’importance d’une revue de code attentive.

Notes supplémentaires

Cohérence des attributs data : vérifiez deux fois que les attributs data comme data-product-id sont correctement définis.
Relisez les dépendances JavaScript : assurez-vous que tous les plugins ou composants JavaScript liés au panier sont bien chargés et initialisés.
Videz le cache : après les changements, videz le cache Shopware et celui de votre navigateur pour éviter que des fichiers obsolètes ne causent des problèmes.

10. Améliorations du Rule Builder

Aperçu du changement

L’API Rule Builder a été étendue pour prendre en charge une logique conditionnelle plus complexe.

Impact

Les règles et conditions personnalisées peuvent nécessiter des ajustements afin de s’aligner sur les nouvelles interfaces ou méthodes fournies par le Rule Builder amélioré.

Action requise

Relisez la documentation du Rule Builder et mettez à jour les implémentations de règles personnalisées pour garantir leur compatibilité.

Observations

Des capacités de règles plus avancées permettent un ciblage et une personnalisation plus précis dans Shopware. Tirer parti de ces nouvelles fonctionnalités peut mener à une meilleure adaptabilité et à des expériences plus personnalisées pour les utilisateurs finaux.

Conclusion

Shopware 6.5 et 6.6 introduisent plusieurs changements importants dans les classes, les namespaces, les attributs data et les mécanismes de sécurité que les développeurs doivent prendre en compte pour maintenir la compatibilité et profiter des nouvelles fonctionnalités. Mettre à jour votre base de code exige une revue attentive et des tests, mais offre aussi l’occasion d’améliorer les performances, la sécurité et la fonctionnalité.

Recommandations

Planifiez en amont : avant la mise à jour, relisez les notes de version officielles et les guides de mise à niveau de Shopware pour obtenir une vue complète.
Testez soigneusement : appliquez les changements dans un environnement de staging et effectuez des tests approfondis pour identifier et corriger les problèmes.
Appuyez-vous sur la documentation : utilisez la documentation Shopware et les forums de la communauté pour trouver des indications sur les changements spécifiques.
Restez informé : suivez les futures mises à jour afin d’anticiper les changements à venir et de vous y préparer.

Observations supplémentaires

Attention au détail : de petits changements, comme des traits d’union dans les attributs data ou la suppression de fonctions, peuvent avoir un impact important. Relisez toujours les mises à jour de templates avec soin.
Soutien de la communauté : la communauté Shopware est active et collaborative. Échanger avec d’autres développeurs peut apporter des idées et des solutions à des problèmes courants.
Bonnes pratiques : adopter les bonnes pratiques mises à jour, comme l’usage de JavaScript natif à la place de jQuery et le recours à des stratégies de sécurité modernes, conduit à un code plus propre et plus efficace.
Surveillance des dépréciations : suivre les avis de dépréciation et se préparer aux suppressions futures peut réduire les interruptions pendant les mises à niveau.

En comprenant et en traitant les changements de classes, de namespaces, d’attributs data et de sécurité dans Shopware 6.5 et 6.6, les développeurs peuvent assurer une transition fluide et continuer à construire des solutions e-commerce robustes et durables.

Évolution de Docker Compose : ce qui a changé et pourquoi c’est important

Wed, 20 Nov 2024 00:00:00 GMT

TL;DR : Docker Compose v1 (docker-compose) a été entièrement supprimé en avril 2025. Le champ version dans votre YAML est mort. La clé x-develop est maintenant simplement develop. Le mode watch est prêt pour la production avec initial_sync. Il existe une CVE critique de traversée de chemins (CVE-2025-62725) si vous utilisez include avec des artefacts OCI : mettez à jour vers v2.40.2 ou plus récent. Et oui, Compose est passé de v2 à v5. Les détails ci-dessous.

Publié initialement en novembre 2024. Mis à jour en mars 2026 avec Compose v5, CVE-2025-62725, la suppression de v1, et les nouvelles fonctionnalités de la spécification.

Si vous utilisez Docker Compose depuis un moment, vous avez probablement remarqué que des choses cassaient ou changeaient sous vos pieds. Les deux dernières années ont été l’évolution la plus agressive que Compose ait jamais connue -- et tout n’était pas évident.

J’utilise Compose tous les jours. La plupart de mes environnements de développement tournent dessus. Quand les choses changent, je le remarque. Voici ce qui compte vraiment.

Ce qui a cassé

docker-compose est mort

Pas déprécié. Pas en mode maintenance. Mort. Le binaire autonome docker-compose (la v1 basée sur Python) a été supprimé des runners GitHub Actions et des images Docker officielles en avril 2025 [1]. Si vos pipelines CI/CD référencent encore docker-compose avec un trait d’union, ils sont cassés ou sur le point de l’être.

# This no longer works
docker-compose up -d

# This is the only way now
docker compose up -d

Le docker compose basé sur Go (v2, maintenant v5) est la vraie implémentation depuis 2022. La CLI v1 était sous assistance respiratoire pour compatibilité. Cette assistance est terminée.

Le champ version a disparu

Arrêtez de mettre version: "3.8" en haut de vos fichiers Compose. Cela ne fait rien. Il est ignoré depuis v2 et il est maintenant officiellement déprécié. Les fichiers Compose modernes commencent par services:.

# Stop doing this
version: "3.8"
services:
  web:
    image: nginx

# Just do this
services:
  web:
    image: nginx

Si vous voyez version: dans un tutoriel, ce tutoriel est obsolète.

Autres dépréciations

links -- utilisez les réseaux Docker. Les links sont legacy depuis le lancement de Compose v2.
container_name -- laissez Docker gérer les noms. Les noms codés en dur cassent le scaling et provoquent des conflits.
Syntaxe courte des volumes pour les montages complexes -- utilisez la syntaxe longue avec type, source, target.

Ce qui est nouveau et réellement utile

Mode watch (maintenant prêt pour la production)

C’est la plus grosse amélioration de confort depuis des années. La section develop (anciennement x-develop -- retirez le préfixe x-, ce n’est plus expérimental) permet de définir des règles de surveillance de fichiers qui synchronisent ou reconstruisent automatiquement quand les fichiers changent :

services:
  web:
    build: .
    develop:
      watch:
        - path: ./src
          action: sync
          target: /app/src
        - path: ./package.json
          action: rebuild

Trois actions disponibles (depuis v2.32.0) :

sync -- copie les fichiers modifiés dans le conteneur sans reconstruire
restart -- redémarre le service quand les fichiers changent
rebuild -- déclenche une reconstruction complète

Depuis septembre 2025, il existe aussi initial_sync : cela synchronise tous les fichiers immédiatement au démarrage de docker compose watch, pour que vous n’ayez pas à attendre le premier changement avant de déclencher la synchronisation. Cela a été un point de friction pendant longtemps.

docker compose watch

Plus besoin de reconstructions manuelles pendant le développement. Cela a vraiment changé mon workflow.

Include avec des artefacts OCI

La directive include peut maintenant récupérer des fragments Compose depuis des registres OCI :

include:
  - oci://docker.io/username/my-compose-fragment:latest

Il existe aussi une prise en charge expérimentale des dépôts Git. C’est utile pour partager des définitions de services communes entre projets -- configurations de bases de données, stacks de monitoring, etc.

Mais lisez d’abord la section sécurité ci-dessous. Il y a une CVE.

Prise en charge des GPU

Le passthrough GPU est devenu plus propre. Il existe maintenant une syntaxe plus courte gpus: (v2.30.0+) en plus de l’approche verbeuse deploy.resources.reservations.devices. La prise en charge des GPU AMD a été officiellement intégrée en 2025 -- ce n’est plus seulement NVIDIA.

Élément models

La spécification Compose inclut maintenant un élément models pour définir des modèles IA/ML comme artefacts OCI. Vous pouvez empaqueter des LLMs et des runtimes d’inférence directement dans votre configuration Compose. C’est de niche, mais intéressant si vous faites du travail IA en local.

Dépendances améliorées

Les conditions de depends_on sont devenues plus flexibles :

services:
  web:
    depends_on:
      db:
        condition: service_healthy
        restart: true      # restart web if db restarts
        required: false     # web can start even if db isn't ready

Les options restart: true et required: false sont vraiment utiles pour des environnements de développement locaux plus résilients.

Ce que vous devez savoir

CVE-2025-62725 : traversée de chemins avec include

Si vous utilisez la directive include avec des artefacts OCI, mettez à jour vers v2.40.2 ou plus récent immédiatement [2]. Une vulnérabilité de traversée de chemins permet à un attaquant de sortir du répertoire de cache pendant la résolution de l’artefact. Même un docker compose ps apparemment inoffensif peut la déclencher si votre fichier Compose inclut une référence OCI malveillante.

Docker a corrigé cela avec une vérification validatePathInBase(), mais vous devez être sur la version corrigée.

Compose v5

Docker est passé de v2 à v5 (en sautant 3 et 4 pour éviter la confusion avec les anciennes versions du format de fichier) [3]. Fonctionnellement, v5 est identique aux dernières versions v2, mais elle inclut un SDK Go officiel pour l’accès programmatique -- ce qui signifie que vous pouvez intégrer des fonctionnalités Compose directement dans des applications Go sans appeler la CLI via le shell.

Vérifiez votre version :

docker compose version
# Docker Compose version v5.1.0

Bake est l’outil de build par défaut

Docker Bake (via BuildKit) est maintenant l’outil par défaut pour docker compose build. Il gère mieux que le builder legacy les builds multi-cibles, la compilation multi-plateforme, et les stratégies avancées de cache. Si vous n’avez pas encore regardé les fichiers docker-bake.hcl, cela vaut la peine de comprendre le sujet -- surtout pour les builds multi-services complexes.

Améliorations des healthchecks

Le champ start_interval permet de définir un intervalle de vérification plus rapide pendant la période de grâce au démarrage :

services:
  db:
    healthcheck:
      test: ["CMD", "pg_isready"]
      start_period: 30s
      start_interval: 2s    # check every 2s during startup
      interval: 30s         # then every 30s after
      retries: 3

Cela signifie que vos services dépendants démarrent plus vite sans compromettre les intervalles de healthcheck en production.

Checklist de migration

Si vous n’avez pas mis à jour votre setup Compose depuis un moment :

Supprimez version: de tous les fichiers Compose.
Remplacez docker-compose par docker compose dans tous les scripts et configurations CI.
Renommez x-develop en develop dans les configurations watch.
Mettez à jour vers v2.40.2+ si vous utilisez include (CVE-2025-62725).
Remplacez links par des réseaux Docker si vous les utilisez encore, d’une manière ou d’une autre.
Testez votre CI -- GitHub Actions a mis à jour ses runners vers Compose v2.40.3 en février 2026 [4].

Références

1. Docker Compose v1 removed from runner images (April 2025) -- Annonce GitHub Actions de la suppression de v1.
2. CVE-2025-62725: From "docker compose ps" to System Compromise -- Analyse détaillée d’Imperva sur la vulnérabilité de traversée de chemins avec include.
3. Docker Compose Releases -- Historique officiel des releases, y compris v5.
4. Docker and Docker Compose version upgrades on hosted runners -- Mise à jour des runners GitHub en février 2026.
5. Compose Specification -- Référence officielle des fichiers Compose.
6. Use Compose Watch -- Documentation Docker du mode watch.
7. Enable GPU Support in Docker Compose -- Documentation du passthrough GPU, y compris la prise en charge AMD.
8. Docker Compose Include -- Directive include avec prise en charge OCI et Git.

Déverrouiller la puissance de 'git grep' pour rechercher efficacement dans le code

Wed, 13 Nov 2024 00:00:00 GMT

Dans un vaste royaume rempli d’innombrables rouleaux et manuscrits vivait un érudit nommé Alaric. Sa bibliothèque était immense : un labyrinthe de savoir où les textes anciens se mêlaient aux écrits contemporains, et où les secrets se cachaient entre les lignes. Alaric se retrouvait souvent à chercher une seule phrase insaisissable au milieu de cette mer d’informations, une tâche qui devenait plus intimidante de jour en jour.

Un matin, tandis que le soleil projetait ses rayons dorés sur les tomes poussiéreux, Alaric partit retrouver un concept particulier mentionné dans ses archives, connu seulement sous le nom de « The Whispering Sigil ». Il parcourut des volumes entiers, utilisant ses méthodes habituelles pour passer les pages au crible — des méthodes qui semblaient désormais lentes et imprécises. Plus il avançait, plus il s’empêtrait dans des passages sans rapport, des doublons et des références trompeuses. La frustration monta tandis que les heures devenaient des jours, avec peu de progrès.

Puis un vieux sage rendit visite à Alaric et remarqua sa détresse. Avec un sourire entendu, le sage dit : « Peut-être cherches-tu par le chemin difficile. Il existe une voie cachée, connue seulement de ceux qui organisent leur savoir avec soin. » Intrigué, Alaric écouta le sage lui expliquer une méthode qui resserrait sa recherche, traversait le désordre et menait directement aux textes qu’il cherchait.

Armé de cette nouvelle approche, Alaric essaya de nouveau. Cette fois, le bruit inutile s’effaça. Le chemin vers « The Whispering Sigil » devint clair, et il trouva ce qu’il cherchait avec une rapidité stupéfiante. C’était comme s’il avait déverrouillé une porte secrète dans son labyrinthe, lui donnant un accès immédiat au savoir exact dont il avait besoin.

Pouf ! Le secret était révélé : la puissance de git grep.

Ce qu’est réellement `git grep`

Un simple grep -r parcourt le système de fichiers. Il lit consciencieusement tout ce qui se trouve sur son chemin : code source, fichiers de log, sorties de build, ce fichier dump perdu de 4 Mo que votre collègue a oublié de supprimer, l’arbre node_modules tout entier. git grep fait quelque chose de plus étroit : il cherche dans les fichiers que Git connaît déjà. C’est de ce choix de conception que vient l’essentiel de sa valeur.

Là où `git grep` est bon

Il cherche dans les fichiers suivis, pas dans le système de fichiers. Git garde une liste de chaque fichier que vous avez déjà staged ou commit — l’index. git grep lit depuis cette liste. Les déchets non suivis n’y sont tout simplement pas. Pas de node_modules/, pas de dist/, pas de rapports de couverture, pas de fichier de log aléatoire — parce que Git n’a jamais été informé de leur existence.
Il est plus rapide que grep -r sur les gros dépôts. Il possède déjà la liste des fichiers, donc il évite de parcourir le système de fichiers. Il lance plusieurs threads en parallèle. Le gain est réel, mais ce n’est pas de la magie. git grep itère sur les mêmes blobs que grep, simplement avec moins de cérémonie. Il n’y a pas d’index de recherche de contenu impliqué — « l’index Git » est une liste de chemins de fichiers et de hashes de blobs, pas un index inversé à la Lucene.
Il peut chercher dans n’importe quelle ref sans checkout. C’est la fonctionnalité qui tue. Un tag, une branche, un commit, un objet tree : pointez git grep directement dessus. Pas de git checkout, pas de danse autour du stash, pas de détour loin de ce que vous étiez en train de faire.

Exemples pratiques

Recherche de base

Pour chercher un terme précis, comme "initializeSettings", dans votre dépôt :

git grep "initializeSettings"

Cela scanne tous les fichiers suivis dans la branche courante pour trouver la correspondance exacte.

Recherche insensible à la casse

Pour une recherche insensible à la casse, utile quand vous n’êtes pas sûr de la capitalisation :

git grep -i "initializesettings"

Cela trouvera les correspondances quelles que soient les différences de casse.

Chercher dans une branche précise

Pour chercher dans une autre branche sans basculer dessus, par exemple dans feature/login :

git grep "validateUser" feature/login

C’est le geste difficile à battre. Pas de checkout, pas de stash, juste la réponse.

Chercher dans toutes les branches

Pour chercher un terme dans toutes les branches, y compris les remotes :

git branch -a | xargs -n 1 git grep "configureDatabase"

Pour chercher dans chaque commit dont Git a entendu parler, pas seulement à la pointe des branches :

git grep "configureDatabase" $(git rev-list --all)

Cela trouve les correspondances dans n’importe quel blob, n’importe où dans votre historique. Sur un dépôt actif, cela peut prendre un moment : il parcourt littéralement chaque commit.

Chercher dans l’historique des commits

Pour trouver quand une chaîne particulière a été ajoutée ou supprimée, utilisez :

git log -S "optimizePerformance"

Cela affiche les commits qui ont introduit ou supprimé le terme "optimizePerformance".

Pour voir les diffs réels où le terme a été ajouté ou supprimé :

git log -G "optimizePerformance" -p

Utiliser des expressions régulières

git grep prend en charge les expressions régulières pour des recherches plus avancées :

git grep -E "def\s+\w+\("

Cela correspond aux définitions de fonctions Python : def, un espace blanc, un nom de fonction, puis une parenthèse ouvrante littérale. (En regex étendue, \( est une parenthèse littérale et ( signifierait un groupe, d’où la barre oblique inverse.)

Ce que `git grep` lit, et ne lit pas

git grep parcourt l’index. C’est tout. Il ne parse pas .gitignore. Beaucoup de gens, y compris une version précédente de cet article, affirment qu’il le fait — et l’affirmation est presque vraie, de la même manière que « la Terre est plate » est presque vraie si vous ne regardez jamais qu’un parking.

Les deux ne s’alignent que parce que les fichiers gitignorés sont généralement aussi non suivis. Dès qu’un fichier est à la fois gitignoré et suivi — quelqu’un a lancé git add -f, ou le fichier a été commité avant que la règle existe — git grep le cherchera volontiers. rg, lui, ne le fera pas.

Vous pouvez le prouver en vingt secondes :

mkdir demo && cd demo
git init -q
echo "*.log" > .gitignore
echo "the secret phrase" > tracked.log
git add -f tracked.log .gitignore
git commit -qm init

git grep "secret phrase"   # finds it - the file is tracked, ignore rule notwithstanding
rg "secret phrase"         # finds nothing - rg actually reads .gitignore

La formulation précise est donc : git grep cherche dans les fichiers suivis. Cela saute par hasard la plupart de ce que .gitignore sauterait, mais le mécanisme est différent et le cas limite compte — surtout quand vous traquez une chaîne qui finit par vivre dans un fichier généré que quelqu’un a ajouté de force il y a des années.

Le mécanisme .gitignore n’entre dans git grep que par deux modes explicites :

--untracked — cherche aussi dans les fichiers non suivis. Dans ce mode, git grep respecte .gitignore par défaut et saute les fichiers ignorés (utilisez --no-exclude-standard pour les chercher eux aussi).
--no-index — cherche dans le répertoire courant en ignorant Git entièrement. Utile dans un dépôt quand vous voulez la sémantique de grep tout court. Dans ce mode, git grep ne consulte pas .gitignore par défaut — activez --exclude-standard si vous le voulez.

Le git grep par défaut, sans flags, n’ouvre jamais votre fichier .gitignore.

Quand choisir plutôt `rg`

git grep et rg (ripgrep) ne sont pas vraiment des concurrents. Ils parcourent des choses différentes, et une boîte à outils sérieuse contient les deux.

git grep parcourt l’index : les fichiers suivis, plus toute ref ou tout objet tree que vous lui indiquez.
rg parcourt le système de fichiers : chaque fichier sous le répertoire courant, moins ce que votre .gitignore, .ignore, .rgignore et vos exclusions globales lui disent de sauter.

Chacun fait quelque chose que l’autre ne peut pas faire.

git grep gagne quand vous voulez chercher dans l’historique sans checkout :

git grep "deprecated_api" v2.3.0          # search a tag
git grep "deprecated_api" HEAD~50         # 50 commits ago
git grep "deprecated_api" $(git rev-list --all)   # every commit, ever

rg gagne quand vous voulez réellement la sémantique du système de fichiers avec une bonne gestion de gitignore — y compris un sous-dossier fraîchement cloné que vous n’avez pas encore git add, des fichiers générés dont Git n’a jamais entendu parler, ou un répertoire qui n’est pas un dépôt Git du tout :

rg "deprecated_api"                # respects .gitignore by default
rg --no-ignore "deprecated_api"    # opt back into ignored files
rg --hidden "deprecated_api"       # include dotfiles

rg est aussi le moteur derrière la recherche de projet de VS Code, ce qui explique pourquoi « Find in Files » ressemble exactement à un rg lancé dans un terminal. Il gère solidement Unicode, et sur la plupart des corpus modernes, il est au moins aussi rapide que git grep, souvent plus rapide — le benchmark du noyau Linux dans le README de ripgrep montre ripgrep battant git grep -P d’environ 3x sur la même requête. (Astuce : si vous voulez le comportement « sensible à la casse seulement quand le motif contient une majuscule », passez -S pour smart-case — c’est opt-in, pas le défaut.)

Si vous n’avez pas encore installé rg, corrigez ça :

brew install ripgrep   # macOS
apt install ripgrep    # Debian/Ubuntu
cargo install ripgrep  # anywhere with Rust

Mettez rg à côté de git grep dans votre boîte à outils. Ils couvrent des tâches différentes.

Avantages de `git grep`

Pertinence. Il cherche seulement dans ce que vous suivez. Les sorties de build, caches et node_modules ne sont pas sur votre chemin — parce que Git ne les a jamais vus.
Vitesse sur les gros dépôts. Multi-threadé, sans parcours du système de fichiers.
Portée historique. Toute branche, tout tag ou tout commit, sans quitter votre working tree. C’est la partie que rg ne peut pas faire.
Moins de bruit binaire. Comme grep, git grep signale les binaires avec « Binary file X matches » au lieu de déverser des octets — mais comme il parcourt les fichiers suivis, il en rencontre généralement moins dès le départ. Passez -I pour ignorer entièrement les binaires.

Conseils supplémentaires

Paginer les résultats :
```
git grep "searchTerm" | less
```
Compter les correspondances par fichier :
```
git grep -c "searchTerm"
```
Afficher les numéros de ligne :
```
git grep -n "searchTerm"
```
Ouvrir chaque correspondance dans votre éditeur :
```
git grep -l "searchTerm" | xargs code
```
Remplacez code par nvim, subl, ou ce que vous utilisez.

Conclusion

Tout comme Alaric a trouvé un chemin caché dans sa bibliothèque labyrinthique, git grep trace une ligne nette à travers une base de code suivie : rapide, conscient des branches, et dégagé de tout ce dont Git n’a jamais entendu parler. Ce n’est pas un remplacement universel de grep, et ce n’est pas un remplacement de rg. C’est l’outil qui connaît l’index de votre dépôt, et une fois que vous l’atteignez, le labyrinthe devient beaucoup plus petit.

Utilisez git grep quand la question est « où dans cette base de code, y compris dans son historique ». Utilisez rg quand la question est « où sur le disque, en respectant mes règles d’ignore ». La plupart des jours, vous voudrez les deux à portée de main.

Mis à jour le 2026-04-27 : correction d’une affirmation précédente selon laquelle git grep respecte .gitignore (ce n’est pas le cas directement), assouplissement de l’explication sur « l’indexation interne », correction d’un exemple de regex, et ajout d’une section sur le moment où utiliser plutôt rg.

PHP 8.3.6 + IMAP sur macOS avec phpenv : guide d'installation

Sun, 01 Sep 2024 00:00:00 GMT

Important (mise à jour 2024-11) : PHP 8.4 a retiré ext-imap du cœur. L'extension a été déplacée vers PECL et elle est, dans les faits, dépréciée -- la bibliothèque C sous-jacente (libc-client) n'a pas été mise à jour depuis 2018. Si vous démarrez un nouveau projet ou si vous êtes sur PHP 8.4+, allez directement à Avez-vous vraiment besoin de ext-imap ? pour des alternatives modernes. Si vous êtes sur PHP 8.3 ou une version antérieure et que vous avez besoin de l'extension native, ce guide fonctionne toujours.

La correction rapide

Si vous voulez simplement les commandes, sans vous soucier du pourquoi -- voici tout, dans l'ordre. Vous devez déjà avoir installé Homebrew et phpenv.

# 1. Install all required libraries
brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

# 2. Set build configuration (add to ~/.zshrc or run before install)
export PHP_BUILD_CONFIGURE_OPTS="--with-openssl=$(brew --prefix openssl@3) \
  --with-zlib=$(brew --prefix zlib) \
  --with-bz2=$(brew --prefix bzip2) \
  --with-curl \
  --with-libedit \
  --with-readline=$(brew --prefix readline) \
  --with-gettext=$(brew --prefix gettext) \
  --with-iconv=$(brew --prefix libiconv) \
  --with-sodium=$(brew --prefix libsodium) \
  --with-kerberos=$(brew --prefix krb5) \
  --with-imap=$(brew --prefix imap-uw) \
  --with-imap-ssl=$(brew --prefix openssl@3) \
  --with-tidy=$(brew --prefix tidy-html5) \
  --enable-mbstring \
  --enable-intl"

# 3. Help the compiler find headers
export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

# 4. Build and install
phpenv install 8.3.6
phpenv global 8.3.6

# 5. Verify
php -v
php -m | grep imap

Si imap apparaît dans la sortie, c'est terminé. Sinon, continuez.

Avez-vous vraiment besoin de ext-imap ?

Question sérieuse. Avant de vous battre avec des bibliothèques C et des flags de compilation, demandez-vous si vous avez vraiment besoin de l'extension IMAP native.

PHP 8.4 a retiré ext-imap du cœur. Elle a été déplacée vers PECL, et la bibliothèque C sous-jacente (libc-client / UW-IMAP) n'a pas reçu de mise à jour depuis 2018. Elle a des problèmes de thread-safety, pas de support XAUTH, et des bugs POP. Elle ne reviendra pas.

L'alternative moderne est Webklex/php-imap -- une implémentation IMAP en pur PHP :

composer require webklex/php-imap

C'est tout. Pas de dépendances brew, pas de flags de compilation, pas de chasse aux fichiers d'en-tête. Elle fonctionne sur PHP 8.0.2+ (y compris 8.4 et 8.5), prend en charge IMAP IDLE et OAuth, et compte plus de 5 millions d'installations sur Packagist. Il existe aussi une intégration Laravel si c'est votre stack.

N'utilisez ext-imap que si vous maintenez une base de code legacy sur PHP 8.3 ou une version antérieure, qui dépend déjà des fonctions imap_*, et que vous ne pouvez pas encore migrer.

Ce que fait chaque étape

Si la correction rapide a fonctionné, vous pouvez arrêter de lire. Si elle n'a pas fonctionné -- ou si vous voulez comprendre ce qui se passe -- voici le détail.

Les dépendances Brew

brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

macOS fournit certaines d'entre elles, mais phpenv a besoin des versions Homebrew, avec les bons headers et fichiers pkg-config. La dépendance critique est imap-uw -- c'est la bibliothèque UW-IMAP qui fournit libc-client.

PHP_BUILD_CONFIGURE_OPTS

phpenv utilise php-build sous le capot, qui lance ./configure sur les sources de PHP. La variable PHP_BUILD_CONFIGURE_OPTS passe des flags directement à configure. Chaque flag --with-* indique à PHP où trouver une bibliothèque précise.

Les plus importants pour IMAP :

--with-imap=$(brew --prefix imap-uw) -- pointe vers la bibliothèque IMAP
--with-imap-ssl=$(brew --prefix openssl@3) -- active IMAP via SSL
--with-kerberos=$(brew --prefix krb5) -- requis pour l'authentification IMAP

La correction CPPFLAGS

export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

Même avec les flags configure, le préprocesseur C n'arrive parfois pas à trouver les fichiers d'en-tête. Cela arrive parce que macOS ne met pas les headers Homebrew dans le chemin de recherche par défaut. Les deux headers qui échouent le plus souvent :

openssl/ssl.h -- depuis OpenSSL
imap/imap.h -- depuis imap-uw

La correction PATH

Si php -v affiche la mauvaise version après l'installation, les shims de phpenv ne sont pas dans votre PATH (ou autre chose les masque). Ajoutez ceci à ~/.zshrc :

export PHPENV_ROOT="$HOME/.phpenv"
if [ -d "${PHPENV_ROOT}" ]; then
  export PATH="${PHPENV_ROOT}/shims:${PHPENV_ROOT}/bin:$PATH"
  eval "$(phpenv init -)"
fi

Puis lancez source ~/.zshrc et réessayez.

L'erreur utf8_mime2text

Si vous voyez ceci :

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing.
This should not happen.

Votre bibliothèque imap-uw est obsolète ou cassée. Corrigez-la avec :

brew upgrade imap-uw

Puis relancez l'installation.

L'avenir de PHP + IMAP

Tout est déjà annoncé. ext-imap est dépréciée, la bibliothèque C sous-jacente est abandonnée, et PHP 8.4 l'a déjà retirée du cœur. Si vous lisez ceci parce que vous avez besoin d'IMAP dans un projet PHP, commencez à planifier votre migration vers webklex/php-imap. L'extension native vit sur du temps emprunté.

Pour celles et ceux d'entre nous qui maintiennent des bases de code legacy -- ce guide continuera à fonctionner pour PHP 8.3 et les versions antérieures. Mais ne démarrez pas de nouveaux projets avec ext-imap. Il n'y a aucune raison de se battre avec la compilation d'une bibliothèque C quand une solution en pur PHP existe.

Références

PHP 8.4: IMAP Extension Unbundled -- Documentation PHP.Watch sur le retrait de ext-imap.
Webklex/php-imap on GitHub -- Implémentation IMAP en pur PHP (5M+ installations Packagist).
PHP Manual: IMAP Extension -- Documentation officielle avec avis de dépréciation.
shivammathur/extensions: IMAP for PHP 8.3+ -- Tap Homebrew pour les extensions PHP, dont IMAP.

Laravel Sail vs Laradock : comparaison pour développeurs PHP avec Docker

Thu, 08 Aug 2024 12:00:00 GMT

TL;DR : Pour la plupart des développeurs Laravel en 2026 : utilisez Laravel Herd si vous voulez zéro friction (natif, sans Docker, installé en quelques secondes). Utilisez Sail si votre équipe a besoin d'environnements identiques ou si vous dépendez de services comme Redis/Meilisearch. Utilisez Laradock si vous travaillez avec plusieurs frameworks PHP. Utilisez une configuration Docker Compose personnalisée si vous avez dépassé les abstractions. Et si la performance est absolument centrale, regardez FrankenPHP + Octane.

Publié initialement en août 2024. Mis à jour en mars 2026 avec Laravel 12/Herd/FrankenPHP et l'état actuel de l'écosystème.

La question était autrefois : « Sail ou Laradock ? » Ce cadrage est trop étroit maintenant. La vraie question est : comment devrais-je configurer mon environnement de développement Laravel en 2026 ? Il y a plus d'options que jamais, et le meilleur choix dépend de ce dont vous avez réellement besoin.

J'ai utilisé la plupart de ces outils. Aujourd'hui, j'utilise une configuration Docker Compose personnalisée parce que je veux garder un contrôle complet sur mes conteneurs, sans abstractions qui cachent ce qui se passe. Mais c'est ma préférence, pas une recommandation universelle. Voyons ce que chaque option vous apporte.

Les concurrents

Laravel Herd

Herd est l'option la plus récente et, pour beaucoup de développeurs, la bonne. C'est une application native (macOS et Windows -- pas encore Linux) qui vous donne PHP, Nginx, Node.js et Dnsmasq sans Docker. La version Pro ajoute MySQL, PostgreSQL, Redis et des outils de débogage.

La fonctionnalité décisive : changer de version PHP en quelques secondes (de 7.4 à 8.4), router automatiquement les domaines *.test, et n'avoir aucun surcoût Docker. Si vous construisez une application Laravel standard et que vous n'avez pas besoin de services exotiques, Herd vous fait écrire du code en moins d'une minute.

Laravel Sail

Sail est l'environnement de développement officiel de Laravel basé sur Docker. Il enveloppe Docker Compose avec une CLI sail qui abstrait les commandes courantes (sail up, sail artisan, sail php).

Depuis Laravel 12, Sail arrive avec PHP 8.5 par défaut, utilise compose.yaml (le nom de fichier moderne, pas docker-compose.yml) et inclut Swoole pour Octane prêt à l'emploi. Il prend aussi en charge la génération de devcontainer via --devcontainer pour l'intégration VS Code/GitHub Codespaces.

Services par défaut : PHP, MySQL, Redis, Meilisearch, Mailpit et Selenium.

Laradock

Laradock est le couteau suisse. C'est un environnement Docker open source qui prend en charge n'importe quel projet PHP -- pas seulement Laravel. Il propose plus de 70 services préconfigurés et peut être configuré pour la production.

Il est toujours activement maintenu en décembre 2025 (mises à jour récentes des images PHP-FPM et workspace). Le compromis, c'est la complexité : l'installation prend plus de temps, la configuration implique de modifier plusieurs fichiers, et il faut une vraie connaissance de Docker.

FrankenPHP + Octane

FrankenPHP est un serveur d'applications PHP moderne construit sur Caddy. Combiné à Laravel Octane, il atteint un temps de démarrage du framework de 4 à 6 ms par requête -- un développeur a rapporté une latence passée de 7 secondes à 66 ms en basculant vers le Worker Mode [1].

Laravel Cloud utilise FrankenPHP dans son runtime Octane en production [2]. La dernière version (v1.11.2, février 2026) a apporté un CGO 30 % plus rapide et un ramasse-miettes 40 % plus rapide grâce à Go 1.26.

Ce n'est pas un environnement de développement au sens traditionnel -- c'est un runtime PHP de niveau production que vous pouvez aussi utiliser en développement. Sail inclut une intégration pour exécuter Octane avec FrankenPHP ou Swoole.

Quand utiliser quoi

Voici mon avis honnête, basé sur l'utilisation réelle de ces outils :

Utilisez Herd si vous êtes seul ou dans une petite équipe, que vous construisez des applications Laravel standard, et que vous voulez passer zéro temps sur l'infrastructure. C'est le chemin le plus rapide entre « j'ai une idée » et « j'écris du code ». La limite, c'est qu'il n'existe que pour macOS/Windows et que la version gratuite n'inclut pas les bases de données.

Utilisez Sail si votre équipe a besoin de parité d'environnement, que vous dépendez de versions précises de services (Redis 7, MySQL 8, PostgreSQL 15), ou que vous travaillez dans une chaîne CI/CD qui a besoin de Docker. La commande sail:publish de Sail vous permet de personnaliser la configuration Docker quand vous dépassez les valeurs par défaut.

Utilisez Laradock si vous travaillez avec plusieurs frameworks PHP (Symfony, Shopware, PHP vanilla), que vous avez besoin de services exotiques (Aerospike, RethinkDB, Manticore), ou que vous voulez un seul environnement Docker pour plusieurs projets. La courbe d'apprentissage est plus raide, mais la flexibilité est inégalée.

Utilisez une configuration Docker Compose personnalisée si vous avez dépassé Sail et Laradock et que vous voulez un contrôle complet. C'est ce que je fais. Je maintiens mon propre compose.yaml avec exactement les services dont j'ai besoin, sans couche d'abstraction, et avec des alias Docker Compose pour garder les commandes courtes. Cela demande plus de travail au départ, mais il n'y a pas de magie -- tout est explicite.

Utilisez FrankenPHP + Octane si vous construisez une API à haute performance ou si votre application est sensible à la latence. L'écart de performance n'est pas marginal -- c'est un ordre de grandeur. Cela vaut la peine de l'explorer, même si vous utilisez un autre outil pour le développement général.

Les détails qui comptent

Temps d'installation

Outil	Temps avant la première requête
Herd	Moins d'une minute
Sail	5-10 minutes (téléchargement des images)
Compose personnalisé	30-60 minutes (configuration initiale)
Laradock	1-2 heures (configuration complète)

Personnalisation

Sail est volontairement limité. Vous obtenez les services dont Laravel a besoin, et pas beaucoup plus. Vous pouvez personnaliser en lançant sail:publish et en modifiant les Dockerfiles, mais à ce stade vous maintenez une configuration Docker personnalisée avec les abstractions de Sail par-dessus -- le pire des deux mondes.

Laradock vous donne tout, mais exige que vous compreniez ce que vous activez. Activer un service signifie modifier .env et peut-être docker-compose.yml, et certains services ont leurs propres répertoires de configuration.

Compose personnalisé vous donne exactement ce que vous écrivez. Rien de plus, rien de moins.

Prêt pour la production

Sail n'est explicitement pas destiné à la production. Laradock peut être configuré pour la production, mais vous devez savoir ce que vous faites en matière de durcissement de sécurité, de limites de ressources et de réseau correct. FrankenPHP est prêt pour la production par conception -- il est construit pour ça.

Support multi-projets

Sail : un projet par environnement. Vous pouvez lancer plusieurs instances Sail, mais elles vont se battre pour les ports.

Laradock : conçu pour les configurations multi-projets. Un environnement, plusieurs projets, services partagés.

Compose personnalisé : ce que vous décidez d'architecturer. Je garde des fichiers compose séparés par projet, avec des définitions de réseau partagées.

Ce que j'utilise vraiment

Docker Compose personnalisé. J'ai des alias pour tout -- dcu pour docker compose up -d, dce pour exec, dcefpm pour l'accès shell PHP-FPM, et une fonction sail qui découvre automatiquement la racine du projet. La configuration est dans mes notes d'évolution Docker Compose.

J'ai commencé avec Laradock il y a des années, je suis passé à Sail à son lancement, puis j'ai fini par me poser sur une configuration personnalisée parce que je voulais comprendre exactement ce qui tournait et pourquoi. Chaque abstraction cache des décisions. Parfois c'est très bien. Parfois ces décisions cachées causent des problèmes difficiles à déboguer parce qu'on ne peut pas les voir.

Cela dit, si je démarrais aujourd'hui un nouveau projet Laravel avec une équipe qui ne se soucie pas des entrailles de Docker, j'utiliserais Sail. Et si j'accompagnais quelqu'un qui débute avec Laravel, je lui dirais d'installer Herd et de commencer à écrire du code immédiatement.

Autres options à mentionner

DDEV -- basé sur Docker, bon support Laravel, feuille de route 2026 active avec intégration Gitpod prévue. À évaluer si vous l'utilisez déjà pour d'autres projets CMS (WordPress, Drupal).
Lando -- une autre couche d'abstraction Docker avec un plugin Laravel (v1.10.0, janvier 2026). Philosophie similaire à Sail, mais agnostique côté framework.
Valet -- le prédécesseur de Herd. Il fonctionne toujours, mais Herd l'a supplanté pour la plupart des usages.

Références

1. Configurer et accélérer Laravel avec FrankenPHP Worker Mode -- Comparaison de performance en conditions réelles : latence de 7 s à 66 ms.
2. Comment Laravel Cloud utilise FrankenPHP en production -- Conférence DevConf sur le runtime Octane de Laravel Cloud.
3. Documentation Laravel 12.x Sail -- Documentation officielle de Sail avec les changements PHP 8.5 et compose.yaml.
4. Laravel Herd -- Site officiel de l'environnement de développement Laravel natif.
5. Publication de FrankenPHP v1.11.2 -- Version de février 2026 avec améliorations de performance et correctifs de sécurité.
6. Laradock sur GitHub -- Toujours maintenu, mises à jour de décembre 2025.
7. L'état actuel du développement Laravel local -- Vue d'ensemble de l'écosystème par Andrew Schmelyun.

Le pire hypocrite : conte d'amour de soi d'un canard en caoutchouc

Wed, 17 Jul 2024 12:00:00 GMT

De Boris à une amie chère : ~ La personne que j'ai toujours eu du mal à comprendre, mais la plus compréhensive de toutes. ~

Salut toi. Rebonjour. Est-ce qu'on peut se rencontrer de nouveau pour la première fois ? Oui. Je crois que cette fois ce sera plus cool. Je serai plus mièvre que jamais 🧀, j'essaierai de te faire rire davantage mais j'échouerai encore parfois, ou la plupart du temps, ou peu importe... Ce sera presque comme la dernière fois mais pas comme la dernière fois. Note : tu peux faire semblant que ma dernière phrase a du sens, juste pour le raffinement 🥸

Laisse-moi commencer par fournir un petit dictionnaire, ou une intro, ou une petite base de connaissances :

Un « commencement » à l'envers, ça fait « tnemecnemmoc »

J'avais juste besoin d'un nouveau titre pour que mon paragraphe soit plus joli. Bref, nouveau moi. Nouvelle toi. Vieux vêtements et quelques vieilles mauvaises habitudes. Ouf !

Un miroir sur le mur

Tu m'as beaucoup manqué et j'ai longtemps repensé à mes erreurs. Les miroirs existent bien pour nous rendre plus jolis et moins sales.

Un canard en caoutchouc

C'est moi. Je suis un canard en caoutchouc. Je suis fait de caoutchouc, et ça veut dire que ma tête aussi est faite de caoutchouc.

Les canards en caoutchouc ne font pas « coin-coin ». Ou si ?

Dans mon humble expérience de vie de canard en caoutchouc, je fais bien « coin-coin » et je le fais assez souvent. 😆

Un canard en caoutchouc qui fait coin-coin fait coin-coin

Coin ! Coin ! Coin ! - dit le canard, et il fit encore coin-coin. Quel son incroyable ! N'est-ce pas ?

Un canard en caoutchouc qui a du caractère

Je suis le plus gentil canard en caoutchouc de tous, dit le canard en caoutchouc en faisant coin-coin avec enthousiasme ! Coin !

La vraie chute des canards en caoutchouc

Faire coin-coin peut être assez épuisant, tu sais. On ne peut faire coin-coin gentiment qu'un nombre limité de fois avec une bonne bouffée d'air frais. Mais tu peux quand même essayer de faire coin-coin gentiment quand tu es vide ? N'est-ce pas ? Bien sûr que tu peux ! Tu peux essayer de faire coin-coin ! Tu peux même donner le meilleur quickity-quack de ton caoutchouc pour aider les autres canards en caoutchouc vides à reprendre une bouffée d'air.

Une courte histoire pour deux canards en caoutchouc à moitié vides

« Tu sais quoi ? » - dit Duckitty « Quoi ? » - dit Duckleton « Quand je fais trop coin-coin, je ne peux plus faire coin-coin, et je veux faire coin-coin, et ça me rend triste. » - répondit Duckitty Duckleton prit un air très sérieux, fronça les sourcils et dit d'une voix sage : « Oui. Je ressens la même chose ! »

Le canard en caoutchouc qui détestait être silencieux

Duckleton détestait être silencieux et poussait un grand coin-coin dès qu'il le pouvait. Parfois, il était assez vide et se demandait s'il était assez jaune pour faire coin-coin. Mais tu vois, l'usine qui avait fabriqué Ducleton et Duckitty les avait faits tous les deux parfaitement jaunes. Duckleton était un canard en caoutchouc qui avait du caractère. Il pensait qu'il pouvait et qu'il devait surpasser tous les autres canards en coin-coin pour les sauver de la honte de ne pas faire coin-coin quand ils étaient vides. Duckitty avait parfois des pensées semblables, ou du moins Duckleton pensait ainsi quand il avait toute sa tête. (Parfois, ce n'était pas le cas 😆) Mais Duckleton était un fier canard en caoutchouc. Un canard en caoutchouc fabriqué dans la meilleure usine du Monde, celle qui fabriquait depuis des siècles les meilleurs canards en caoutchouc jaunes qui faisaient coin-coin. En tout cas, Duckleton pensait ainsi jusqu'à ce qu'il rencontre Duckitty. Une fois qu'il l'eut rencontrée, il fut tellement émerveillé par sa voix qu'il pensa qu'elle devait avoir été fabriquée dans une usine extraterrestre, bien meilleure que l'usine terrestre d'où il venait. Il était heureux d'avoir la chance d'admirer simplement cette merveilleuse et parfaite canarde en caoutchouc, bien meilleure que lui (pensait-il), nommée Duckitty. « Eh bien, c'est tellement agréable de la regarder. Elle est si jaune. Elle est si gentille. Elle a une voix bien plus jolie que la mienne. Je suis un canard en caoutchouc chanceux. » - pensait Duckleton.

Une histoire courte mais un peu triste

Duckleton et Duckitty étaient tous les deux heureux et faisaient coin-coin comme si c'était le meilleur concours de coin-coin du Monde et de l'espace intersidéral. Un jour, un enfant humain arriva et pressa Duckleton. Il fut incapable de faire coin-coin pendant quelque temps, mais il en avait toujours très envie ; alors il resta silencieux sans se plaindre, prit une grande inspiration, et ils continuèrent tous les deux à faire coin-coin joyeusement. Un peu de temps passa, et Duckitty fut elle aussi prise par un méchant enfant humain. L'enfant humain expulsa tout l'air de Duckitty en la pressant, mais Duckleton était trop occupé à faire coin-coin pour le remarquer. Duckitty allait bien, mais elle devait reprendre un peu d'air. Duckleton était triste au-delà du désespoir. Il pensait que sa canarde préférée était cassée et qu'il serait de nouveau seul pour toujours jusqu'à la fin de l'Univers. Il avait simplement oublié que le même enfant l'avait pressé quelque temps auparavant. Duckleton était fier mais bête ; après tout, il avait une petite tête en caoutchouc. Quand Duckitty fit coin-coin, Duckleton fut furieux. Il était à la fois heureux qu'elle soit en vie, mais il était aussi un peu découragé, parce qu'il pensait que Duckitty pouvait mieux survivre que lui à la pression d'un enfant humain. Elle était tellement plus parfaite que lui, après tout, non ?

Le voyage de culpabilité de Duckleton

Duckleton était le pire hypocrite de tous et il finit par l'apprendre. Il était triste, mais il pensa : Allons présenter mes excuses à Duckitty et lui montrer un peu de gratitude pour être aussi parfaite qu'elle l'est.

Épilogue

Ma chère amie, tu as été parfaite pendant les 8 dernières années. Tu as été parfaite chaque jour. Je suis vraiment désolé d'avoir été un tel hypocrite, mais les mauvaises choses arrivent, tu sais. Et on continue quand même. S'il te plaît, aime-toi beaucoup plus. Je suis bête. Tu es intelligente. Ou peu importe... Mais aime-toi beaucoup plus, parce que tu es parfaite telle que tu es ! En fait, tu es la canarde en caoutchouc jaune la plus parfaite du Monde. Du moins, c'est ce que je pense. Ma tête en caoutchouc est petite. Mais, youpi ! Je peux encore penser. 🫶 Coin !

Coin, Coin, Coin ~ Duckleton

Représentations discrètes en RL : les enseignements de la recherche d'Edan Meyer

Mon, 15 Jul 2024 00:00:00 GMT

Vous êtes-vous déjà demandé comment les agents d'IA apprennent à comprendre des environnements complexes et à interagir avec eux ? Edan Meyer, chercheur dans le domaine de l'apprentissage par renforcement (RL), explore une approche intrigante qui pourrait bien changer notre manière de penser l'apprentissage de l'IA. Plongeons dans son travail fascinant sur les représentations discrètes en RL !

Le pouvoir de la représentation

Imaginez que vous essayiez d'apprendre à un ordinateur à jouer à un jeu vidéo. Comment représenteriez-vous l'état du jeu d'une manière que l'ordinateur puisse comprendre et dont il puisse apprendre ? C'est là qu'intervient l'apprentissage de représentations, et c'est un élément crucial pour créer des agents d'IA efficaces.

Edan Meyer, dont vous pouvez découvrir le travail sur sa chaîne YouTube, étudie un type particulier de représentation appelé représentations discrètes. Ses recherches, détaillées dans un article disponible sur arXiv, éclairent pourquoi ces représentations pourraient être particulièrement utiles dans certains scénarios de RL.

Deux ans de recherche en 13 minutes

Edan a condensé deux années de recherche de master dans une vidéo captivante de 13 minutes intitulée "2 Years of My Research Explained in 13 Minutes". Dans cette vidéo, il décompose des concepts complexes en explications assimilables, rendant son travail accessible à un public plus large.

Comme Edan l'écrit dans la description de sa vidéo :

"Voici mes recherches sur l'apprentissage de représentations et l'apprentissage de modèles dans le cadre de l'apprentissage par renforcement. Deux ans de travail, et je peux enfin parler de ma recherche de master ! L'article a été accepté à la Reinforcement Learning Conference (RLC) 2024."

Cette vidéo offre un excellent point de départ pour quiconque veut comprendre les bases de ses recherches sans se plonger dans l'article académique complet.

Que sont les représentations discrètes ?

Traditionnellement, beaucoup de systèmes de RL utilisent des représentations continues : pensez à des vecteurs de nombres décimaux qui peuvent prendre n'importe quelle valeur. Les représentations discrètes, à l'inverse, ressemblent davantage à une série de questions à choix multiples. Chaque "emplacement" de la représentation ne peut prendre qu'une valeur parmi un nombre fixe de possibilités.

Comme Edan l'explique dans sa vidéo, cela peut sembler limitant au premier abord. Après tout, une valeur continue peut représenter une infinité d'états, tandis qu'une valeur discrète est beaucoup plus contrainte. Alors pourquoi utiliser des représentations discrètes ?

Les bénéfices surprenants

Les recherches d'Edan ont mis au jour plusieurs avantages fascinants à l'utilisation de représentations discrètes :

De meilleurs world models avec moins de capacité : Lorsqu'une IA essaie d'apprendre un modèle de son environnement (un "world model"), les représentations discrètes lui permettent de capturer une information plus précise avec moins de puissance de calcul. C'est particulièrement vrai lorsque le modèle n'a pas assez de capacité pour représenter parfaitement tout ce qui concerne l'environnement, un scénario courant dans les problèmes complexes du monde réel.
Une adaptation plus rapide : Dans des expériences où l'environnement changeait au fil du temps, les agents utilisant des représentations discrètes ont pu s'adapter plus rapidement à ces changements. Cela pourrait être crucial pour des systèmes d'IA qui doivent fonctionner dans des environnements dynamiques et imprévisibles.
Un apprentissage efficace : Même si les représentations discrètes peuvent demander plus de temps à apprendre au départ, une fois établies, elles permettent un apprentissage et une adaptation plus rapides, aussi bien dans les tâches de world modeling que dans l'apprentissage de politiques.

Pourquoi est-ce important ?

Les implications du travail d'Edan vont bien au-delà de simples expériences en grid-world. Comme il le souligne dans sa vidéo, le monde réel est infiniment plus complexe que n'importe quelle simulation que nous pouvons créer. Dans de tels environnements, il est impossible pour une IA de tout apprendre ; la clé, c'est l'adaptation.

Les représentations discrètes semblent offrir un outil puissant pour créer des systèmes d'IA capables de s'adapter rapidement à de nouvelles situations, même lorsqu'ils ne peuvent pas modéliser tous les aspects de leur environnement. Cela pourrait changer la donne pour des applications allant de la robotique aux jeux de stratégie complexes, et bien au-delà.

Aller plus loin

Pour celles et ceux qui s'intéressent aux détails techniques, l'article d'Edan explore des aspects fascinants de ce qui rend les représentations discrètes si efficaces. Par exemple, il a constaté que toutes les représentations discrètes ne se valent pas : des facteurs comme la parcimonie et la binarité jouent un rôle important dans leur efficacité.

Conclusion

Le travail d'Edan Meyer sur les représentations discrètes en apprentissage par renforcement offre des pistes passionnantes sur la manière dont nous pourrions créer des systèmes d'IA plus adaptables et plus efficaces. En remettant en question les idées reçues sur la façon de représenter l'information pour l'IA, ses recherches ouvrent de nouvelles possibilités pour créer des agents capables de prospérer dans des environnements complexes et dynamiques.

Que vous soyez chercheur en IA, étudiant en machine learning, ou simplement fasciné par les frontières de la technologie, le travail d'Edan offre un aperçu convaincant de l'avenir de l'intelligence artificielle. N'hésitez pas à consulter sa chaîne YouTube, sa vidéo explicative et son article pour explorer ces idées plus en profondeur !

Souvenez-vous : dans le monde très rapide de la recherche en IA, les techniques expérimentales d'aujourd'hui pourraient devenir les technologies de rupture de demain. Les représentations discrètes pourraient bien être la clé qui débloquera des systèmes d'IA plus capables et plus adaptables dans un avenir proche.

Histoire de l'IA chez Google : promesses, bourse et impact

Sat, 11 May 2024 12:00:00 GMT

Le parcours de Google dans le développement et la commercialisation de technologies d'IA telles que la série Gemini offre une étude de cas fascinante sur les rapports entre promesses d'entreprise, performance boursière et innovation technologique. Cette analyse examine des moments historiques précis où les promesses de Google en matière d'IA ont fortement influencé le cours de son action, tout en revenant sur ses réussites et ses échecs.

L'entrée du géant technologique dans l'IA a été marquée par des projets ambitieux et des affirmations audacieuses. Depuis l'introduction de TensorFlow en 2015, qui a installé Google comme un leader de la recherche et du développement en IA, jusqu'au lancement de Google Assistant en 2016, qui a renforcé sa compétitivité face à des rivaux comme Alexa d'Amazon et Siri d'Apple, Google a constamment cherché à repousser les limites des capacités de l'IA [1].

Jalons historiques clés dans le développement de l'IA chez Google

Introduction de TensorFlow (2015) : Google a rendu TensorFlow open source, son framework de machine learning, qui est devenu largement populaire. Cette décision a contribué à établir Google comme un leader de la recherche et du développement en IA, avec un effet positif sur sa perception par le marché [1]. TensorFlow a été utilisé dans diverses applications, de l'amélioration des résultats de recherche à l'alimentation des voitures autonomes.
Lancement de Google Assistant (2016) : L'introduction de Google Assistant a renforcé la compétitivité de Google dans l'IA face à des rivaux comme Alexa d'Amazon et Siri d'Apple. Le marché l'a bien accueilli, y voyant un potentiel de croissance dans les interfaces utilisateur pilotées par l'IA [2]. Google Assistant a été intégré aux smartphones, aux appareils domotiques et aux voitures, ce qui en a fait un acteur clé du marché des assistants vocaux.
Progrès en informatique quantique (2019) : Google a annoncé une percée de suprématie quantique, affirmant que son ordinateur quantique pouvait effectuer des calculs hors de portée des supercalculateurs traditionnels. Cette annonce a provoqué une brève hausse du cours de l'action, illustrant l'enthousiasme des investisseurs pour les capacités technologiques de pointe de Google [3].

Performance boursière et jalons de l'IA

Le marché boursier a réagi de façon variable aux avancées de Google en IA. Les annonces importantes, comme les percées en informatique quantique et les lancements de nouveaux produits d'IA, entraînent généralement des hausses de cours à court terme. Cependant, l'impact à long terme sur le cours de l'action est resté plus étroitement lié au déploiement effectif et au succès commercial de ces technologies.

Jalons du S&P 500 : Les grandes annonces de Google en IA ont souvent coïncidé avec des tendances de marché plus larges. Par exemple, le marché haussier général de 2021 a vu Google atteindre de nouveaux sommets boursiers en même temps que des avancées significatives en IA, reflétant une forte confiance des investisseurs dans la croissance portée par la technologie [4].

Fig1. - Jalons boursiers de Google.

Réussites et échecs

Réussites : L'IA de Google a obtenu des succès considérables dans des domaines comme la traduction automatique, la reconnaissance d'images et les technologies de conduite autonome avec Waymo. Ces réussites ont contribué à consolider la réputation de Google comme innovateur technologique [5].
Échecs : Toutes les initiatives de Google en IA n'ont pas répondu aux attentes du marché. Par exemple, le très attendu projet Google Glass n'a pas trouvé d'écho chez les consommateurs, ce qui a conduit à son abandon. Le produit a suscité des inquiétudes en matière de vie privée et n'a pas offert de cas d'usage convaincant pour le consommateur moyen. De même, les retards et les promesses excessives autour de Gemini 1.5 Pro ont provoqué de l'insatisfaction chez les utilisateurs et du scepticisme [6]. Google a tiré des leçons de ces échecs, en se concentrant sur des applications d'IA plus pragmatiques et en améliorant sa communication avec les utilisateurs.

Fig2. - Jalons IA des entreprises technologiques.

Impact sur le marché et perspectives

L'impact de l'IA de Google sur le marché a été significatif, influençant non seulement le cours de son action, mais aussi l'orientation plus large de l'industrie technologique. Le secteur de l'IA reste un centre d'intérêt majeur pour les investisseurs, comme le montre la performance du S&P 500, où les valeurs technologiques jouent un rôle substantiel [4].

Pour l'avenir, la capacité de Google à tenir ses promesses en matière d'IA et à surmonter les défis du déploiement technologique sera cruciale. Sa stratégie visant à renforcer la transparence et à mieux gérer les attentes des consommateurs pourrait déterminer sa position future sur le marché et la confiance des investisseurs.

Un point clé à surveiller est la progression de Google avec sa série de modèles d'IA Gemini. Gemini 1.5 Pro, annoncé en février 2024, promet un bond important dans les capacités de l'IA, mais son déploiement a rencontré des difficultés [6]. La manière dont Google affrontera ces défis et tiendra ses promesses aura probablement un impact notable sur sa réputation en IA et sur sa position de marché.

Les avancées ambitieuses de Google en intelligence artificielle, en particulier à travers sa série Gemini, marquent une ère transformatrice pour la technologie de l'IA. L'introduction de Gemini 1.5 Pro dans cette série souligne l'engagement de Google à repousser les limites des capacités de l'IA. Cependant, le déploiement de Gemini 1.5 Pro n'a pas été sans difficultés, lesquelles sont essentielles pour comprendre à la fois le potentiel et les limites de modèles d'IA aussi avancés.

Avis d'experts sur Gemini 1.5 Pro

Performance et capacités : Gemini 1.5 Pro, construit sur une architecture Mixture-of-Experts (MoE), apporte des améliorations significatives par rapport aux modèles précédents, notamment une augmentation massive de la fenêtre de contexte, jusqu'à 10 millions de tokens. Cette amélioration permet de mieux traiter des tâches complexes impliquant de grands volumes de données dans divers formats — texte, code, vision et audio [7]. Selon Stephen Oladele d'Encord, "Gemini 1.5 Pro conserve un rappel presque parfait sur l'ensemble du contexte et utilise une architecture mixture-of-experts pour un entraînement plus efficace et des réponses de meilleure qualité" [7].

Difficultés du déploiement : Malgré ses capacités avancées, le déploiement de Gemini 1.5 Pro a rencontré plusieurs difficultés. Le modèle est actuellement en private preview, et sa disponibilité générale est prévue plus tard, ce qui indique une approche de déploiement par étapes [7]. Cette stratégie prudente tient peut-être à la nécessité d'affiner encore le modèle et de s'assurer qu'il réponde aux attentes élevées fixées par ses prédécesseurs et par le marché.

Points de vue des analystes du secteur

Impact sur l'industrie de l'IA : Les analystes du secteur voient la série Gemini comme une avancée importante pour Google, susceptible d'établir de nouveaux standards pour ce que les modèles d'IA peuvent accomplir. La série Gemini, et en particulier le modèle 1.5 Pro, devrait renforcer la compétitivité de Google face à d'autres géants technologiques comme OpenAI et Microsoft, qui ont eux aussi progressé agressivement dans leurs capacités d'IA [8] [7].

Implications pour le marché : Les progrès de Gemini 1.5 Pro sont susceptibles d'influencer divers secteurs, dont la santé, la finance et d'autres encore, en permettant des applications d'IA plus sophistiquées. Cela pourrait entraîner des changements dans la dynamique du marché, où les entreprises capables d'intégrer efficacement de telles technologies d'IA avancées pourraient obtenir un avantage concurrentiel significatif [7].

Éclairages de dirigeants de Google

Plans futurs et considérations éthiques : Les dirigeants de Google, dont Sundar Pichai, ont souligné l'engagement de l'entreprise en faveur d'un développement responsable de l'IA. Pichai a mis en avant l'importance d'aligner les avancées de l'IA avec des lignes directrices éthiques et de veiller à ce que ces technologies soient utilisées au bénéfice de la société [2] [9]. Cette approche est cruciale alors que l'IA devient de plus en plus capable et s'intègre aux applications du quotidien.

Naviguer entre difficultés et opportunités

Répondre aux défis techniques : Pour affronter les défis à venir, Google doit continuer d'investir dans la recherche et le développement afin de traiter des questions comme la fiabilité des modèles et les préoccupations éthiques. L'approche de l'entreprise, qui consiste à déployer progressivement Gemini 1.5 Pro, suggère une stratégie axée sur l'atténuation des risques avant qu'ils ne deviennent des problèmes importants [7].

Élargir les opportunités de marché : Google peut exploiter les capacités de Gemini 1.5 Pro pour créer de nouvelles opportunités de marché, en particulier dans les secteurs qui exigent le traitement de grands ensembles de données et de scénarios complexes de résolution de problèmes. En fournissant des outils qui simplifient l'intégration de l'IA dans les processus métier, Google peut aider les industries à transformer leurs opérations et à gagner en efficacité [10].

Développement éthique de l'IA : À mesure que les technologies d'IA deviennent plus puissantes, leurs implications éthiques prennent davantage d'importance. L'engagement continu de Google en faveur d'un développement responsable de l'IA, tel qu'il se manifeste dans ses principes d'IA et ses cadres de gouvernance, sera crucial pour maintenir la confiance du public et la conformité réglementaire [11].

En conclusion, si le déploiement de Gemini 1.5 Pro présente des difficultés, il offre aussi à Google des opportunités substantielles de prendre la tête dans le domaine de l'IA. En continuant à se concentrer sur l'amélioration des performances, le développement éthique de l'IA et l'expansion du marché, Google peut relever efficacement ces défis et établir de nouveaux standards pour ce que l'IA peut accomplir dans différents secteurs.

Conclusion

Le parcours de Google dans l'IA illustre les dynamiques complexes de l'innovation technologique, des attentes du marché et de la stratégie d'entreprise. Si l'entreprise a connu à la fois des réussites notables et des revers, ses efforts continus dans l'IA continuent d'attirer une attention importante du marché. Les investisseurs et les observateurs du marché garderont probablement un oeil attentif sur la capacité de Google à transformer ses capacités d'IA en croissance durable et en leadership de marché.

Alors que le paysage de l'IA continue d'évoluer rapidement, la position de Google comme pionnier de l'IA sera mise à l'épreuve. Sa capacité à équilibrer innovation ambitieuse et exécution réaliste, communication transparente et gestion efficace des attentes sera un facteur critique pour déterminer son succès à long terme dans le domaine de l'IA et sa performance globale sur le marché.

Références

1. Emeritus - Stratégie IA de Google
2. Blog Google - Gemini AI
3. Yahoo Finance - Cours GOOGL
4. Wikipedia - Jalons du S&P 500
5. Think with Google - Outils d'IA
6. Times of India - Sortie du modèle IA Gemini 15 Pro
7. Encord - Modèle d'IA générative Google Gemini 1.5 avec Mixture of Experts
8. Built In - Google Gemini
9. CBS News - L'avenir de l'IA chez Google
10. Google Cloud - IA générative
11. Blog Google - IA responsable

Photoréalisme avec Stable Diffusion : réglages et limites GPU

Thu, 04 May 2023 23:45:00 GMT

Mis à jour en mars 2026. Cet article a été écrit à l'origine en mai 2023, quand SD 1.5 en 512x512 était la norme et que la RTX 3090 représentait le sommet du matériel. Tout a changé. Flux 2, les fine-tunes SDXL, SD 3.5, ControlNet et la RTX 5090 ont complètement redéfini ce qui est possible. Voici l'état actuel des choses.

L'écart entre les images générées par IA et les vraies photographies s'est presque refermé. En 2023, « photoréaliste » voulait dire « presque convaincant si l'on plisse les yeux ». En 2026, les meilleurs modèles produisent des images qu'il est réellement difficile de distinguer d'une photographie professionnelle.

Voici comment y arriver.

Le paysage actuel du photoréalisme

Le modèle que vous choisissez compte plus que n'importe quel réglage que vous ajustez. Voici où nous en sommes :

Flux 2 -- Le nouveau roi

Flux 2, de Black Forest Labs (sorti en novembre 2025), est probablement le meilleur modèle open-weight pour le photoréalisme en 2026 [1]. Il produit des images avec une lumière naturelle, des textures de peau précises et une composition cohérente qui rivalise avec la photographie professionnelle. Adobe a intégré Flux (Kontext Pro) dans Photoshop en septembre 2025 [2] -- cela dit assez où se situe la confiance de l'industrie.

Flux possède aussi une excellente compréhension du langage naturel. Vous pouvez décrire ce que vous voulez en anglais courant, sans la soupe de mots-clés qu'exigeait SD 1.5.

Fine-tunes SDXL -- Les chevaux de trait

Pour le photoréalisme basé sur SDXL, voici les leaders actuels :

Juggernaut XL v9/v10 -- le choix évident pour un rendu cinématographique et photographique. Le plus populaire chez les photographes et les cinéastes.
Realistic Vision -- fine-tuné spécifiquement pour les textures réalistes, l'éclairage et la précision des visages.
EpicRealism -- détail fin exceptionnel et lumière naturelle.

Ces modèles disposent d'un énorme soutien communautaire, de bibliothèques LoRA très riches et d'un comportement prévisible. Si Flux vous semble trop récent ou si votre workflow repose sur SDXL, ce sont d'excellents choix.

SD 3.5 Large

Le modèle phare de Stability AI utilise la nouvelle architecture Multimodal Diffusion Transformer (MMDiT) -- une approche fondamentalement différente de SDXL. Il est techniquement impressionnant, mais son écosystème est plus petit. SD 3.0 a été déprécié en avril 2025, donc assurez-vous d'être sur 3.5 [3].

Retour à la réalité côté GPU

Les exigences matérielles ont fortement augmenté.

GPU	VRAM	Capacité photoréaliste
RTX 3060 12GB	12GB	Photoréalisme SD 1.5 seulement. SDXL est serré
RTX 4070 Ti	12GB	SDXL en 1024x1024. Flux est possible avec des optimisations
RTX 4090	24GB	Le bon équilibre. Gère confortablement SDXL, Flux et SD 3.5 en 1024x1024+
RTX 5090	32GB	Tout, y compris la génération 4K et les workflows en lot. 32GB GDDR7, bus 512 bits [4]
Cartes 8GB	8GB	Minimum viable avec la gestion VRAM de ComfyUI. Pas confortable

Le bon compromis de 2023, « 512x512 sur une RTX 3080 », appartient à l'histoire ancienne. 1024x1024 est maintenant la résolution standard, et il faut au moins 16GB de VRAM pour travailler sans frustration permanente. À 24GB, les choses deviennent confortables.

Pour le photoréalisme en particulier, plus de VRAM signifie que vous pouvez exécuter simultanément des modèles plus grands, des résolutions plus élevées et ControlNet sans délestage vers le CPU.

Réglages pour le photoréalisme

Sampler

DPM++ 2M Karras à 25-30 steps. C'est le consensus établi pour le photoréalisme SDXL -- le meilleur rapport vitesse/qualité. Si vous voulez un peu plus de détail avec peu de steps, passez à DPM++ SDE Karras.

Pour Flux : utilisez le sampler par défaut à 20-30 steps.

CFG

Pour le photoréalisme SDXL : 7-9. Cela donne une forte adhérence au prompt sans l'aspect sursaturé et trop cuit qui apparaît au-dessus de 10.

Pour SD 3.5 : commencez plus bas (3-5) -- le mécanisme de guidance fonctionne différemment.

Pour Flux : suivez les recommandations propres au modèle, mais en général plus bas que SDXL.

Résolution

Générez à la résolution native du modèle (1024x1024 pour SDXL/SD 3.5/Flux), puis upscalez pour obtenir une résolution supérieure. N'essayez pas de générer directement en 2048x2048 -- vous obtiendrez des artefacts, des éléments dupliqués et des problèmes de composition.

Options d'upscaling : hi-res fix dans A1111, ou des nodes d'upscaling dédiés dans ComfyUI (4x-UltraSharp, ESRGAN).

Prompter pour le photoréalisme

Le grand changement depuis 2023 : écrivez naturellement, pas en mots-clés.

SD 1.5 avait besoin de prompts comme :

portrait of a woman, photorealistic, 8k, ultra detailed, sharp focus,
professional photography, Fujifilm X-T4, 85mm f/1.4

SDXL et Flux comprennent :

A portrait of a woman in soft afternoon light, photographed with a shallow
depth of field. She's looking slightly off-camera with a natural expression.

L'approche en soupe de mots-clés fonctionne encore sur SDXL, mais le langage naturel produit des résultats plus cohérents. Flux, en particulier, excelle avec des prompts descriptifs et conversationnels.

Negative prompts : Gardez-les minimaux. Commencez sans rien, puis ajoutez des corrections précises. « cartoon, illustration, painting » suffit généralement à garder les choses photoréalistes. Voir la cheat sheet pour le changement complet de philosophie autour des negative prompts.

ControlNet change tout

Si vous êtes sérieux au sujet de la composition photoréaliste, ControlNet est non négociable. Il vous permet de contrôler la structure de votre image avec :

Depth maps -- maintenir les relations spatiales et la perspective
Canny edge detection -- préserver les contours et les formes
OpenPose -- contrôler la pose humaine et les proportions du corps
Surface normals -- interaction réaliste de la lumière avec les surfaces

Des modèles ControlNet sont maintenant disponibles pour SDXL, Flux et SD 3.5 [5]. Multi-ControlNet (empiler plusieurs contrôles) vous donne un contrôle précis de la composition que le prompt engineering seul ne peut pas atteindre.

Le workflow : prenez une photo de référence, extrayez une depth map ou une pose, utilisez-la comme entrée ControlNet, puis générez une image photoréaliste avec la même composition.

Vitesse contre qualité

Si vous avez besoin d'itérations rapides (travail de concept, tests de prompts), utilisez SDXL Lightning -- il génère des images 1024px de qualité en 2-8 steps [6]. La qualité est meilleure que SDXL Turbo aux résolutions plus élevées.

Pour le rendu final, revenez à SDXL complet ou à Flux avec 25-30 steps. La différence se voit.

Le workflow pratique

Voici ce qui fonctionne réellement pour une sortie photoréaliste en 2026 :

Choisissez votre modèle -- Flux 2 pour le meilleur photoréalisme, Juggernaut XL pour l'écosystème SDXL
Écrivez un prompt en langage naturel qui décrit ce que vous voyez
Générez en 1024x1024, DPM++ 2M Karras, CFG 7-9, 25-30 steps
Utilisez ControlNet si vous avez besoin d'une composition précise (depth ou pose)
Itérez sur le prompt -- générez 4-8 images, choisissez la meilleure
Upscalez la gagnante vers votre résolution cible
Inpaintez les zones problématiques (mains, yeux, petits détails)

C'est le même workflow, que vous soyez dans ComfyUI ou dans A1111. Les outils diffèrent, pas le pipeline.

Références

1. Modèles Flux 2 -- Black Forest Labs -- Page officielle du modèle Flux 2.
2. FLUX.2 and NVIDIA RTX AI Garage -- Intégration de Flux 2 avec ComfyUI et adoption par l'industrie.
3. Stability AI Release Notes -- Dépréciation de SD 3.0 et détails de la sortie 3.5.
4. RTX 5090 vs 4090 for AI Workloads -- Comparaison matérielle pour la génération d'images.
5. ControlNet Complete Guide -- Documentation ControlNet mise à jour pour plusieurs architectures.
6. SDXL-Lightning by ByteDance -- Modèle de génération en 2-8 steps.
7. Best Stable Diffusion Models for Photorealism 2026 -- Paysage actuel des modèles.
8. Top Photorealistic Stable Diffusion Models -- Revues communautaires Civitai.

Aide-mémoire Stable Diffusion : dépannage et optimisation

Thu, 04 May 2023 23:30:00 GMT

Mis à jour en mars 2026. La version originale de cet aide-mémoire a été écrite pour SD 1.5 en mai 2023. Presque tout a changé depuis -- nouvelles architectures (SDXL, SD 3.5, Flux), nouvelles interfaces (ComfyUI), nouveau matériel (RTX 5090) et renversement complet de la philosophie des prompts négatifs. Voici la version actuelle.

Ceci est ma référence de travail pour les paramètres de Stable Diffusion. Pas un tutoriel -- seulement les réglages que je vais chercher quand quelque chose ne marche pas ou quand je veux pousser la qualité.

Quel modèle utiliser

C'est maintenant la première décision, et elle compte plus que n'importe quel ajustement de paramètre.

Modèle	Idéal pour	Résolution	Notes
Flux 2	Photoréalisme, respect du prompt	1024x1024+	Meilleur modèle open-weight pour le photoréalisme en 2026. Intégré à Adobe Photoshop [1]
SDXL	Usage général	1024x1024	Énorme écosystème de fine-tunes. Juggernaut XL, Realistic Vision, DreamShaper
SD 3.5 Large	Qualité maximale (le fleuron de Stability)	1024x1024	Architecture MMDiT. SD 3.0 a été déprécié en avril 2025 [2]
SDXL Lightning	Vitesse	1024x1024	Génération en 2 à 8 étapes. Meilleure qualité que Turbo à haute résolution [3]
SD 1.5	Workflows hérités	512x512	Immense bibliothèque de fine-tunes, mais en voie d'abandon. SD 2.0/2.1 officiellement dépréciés

Si vous repartez de zéro : Flux 2 pour le photoréalisme, SDXL pour tout le reste. SD 3.5 est bon, mais son écosystème est plus petit.

Quelle interface utiliser

Interface	Idéale pour
ComfyUI	Utilisateurs avancés. Basée sur des nœuds, meilleure gestion de la VRAM, 15 % plus rapide, meilleur support de Flux. Standard industriel pour le travail sérieux depuis 2025 [4]
Automatic1111	Débutants. Interface plus simple, immense bibliothèque d'extensions. Fonctionne encore très bien pour SDXL
Fooocus	Génération en un clic. Configuration minimale. Bien pour des résultats rapides

J'utilise ComfyUI. La courbe d'apprentissage est plus raide (comptez 10 à 20 heures pour être à l'aise), mais la gestion de la VRAM vaut à elle seule l'effort -- il fait tourner SDXL sur 8 Go là où A1111 plante.

Samplers

Le débat sur les samplers est plus ou moins réglé.

Choix par défaut :

DPM++ 2M Karras -- meilleur rapport vitesse/qualité. C'est mon choix par défaut pour presque tout.
DPM++ SDE Karras -- légèrement meilleur avec peu d'étapes. Bon quand vous itérez vite.
Euler a -- toujours fiable. Plus de variété dans les sorties, utile pour explorer.

Quand changer :

Manque de diversité dans les sorties ? Essayez DPM++ SDE ou Euler a.
Artefacts ou sursaturation ? Essayez DPM++ 2M Karras ou Euler simple.
Besoin de vitesse avant tout ? Euler a ou DPM++ 2M (non-Karras).
Vous voulez la qualité maximale ? DPM++ 3M SDE Karras ou UniPC.

Nombre d'étapes : 20 à 30 étapes pour la plupart des samplers. Les modèles Lightning n'en demandent que 2 à 8.

CFG (Classifier Free Guidance)

À quel point le modèle suit strictement votre prompt plutôt que sa propre interprétation.

Plage	Effet
1-4	Très créatif, interprétation lâche. Souvent incohérent
5-7	Bon équilibre pour la plupart des travaux
7-10	Forte adhérence au prompt. Zone idéale pour le photoréalisme avec SDXL
10-15	Risque d'artefacts et de couleurs trop cuites
15+	Presque toujours trop. Artefacts garantis

Note : SD 3.5 utilise un mécanisme de guidance différent. Le concept de CFG s'applique encore, mais l'échelle se comporte autrement -- commencez plus bas (3-5) et ajustez.

Résolution

L'époque du 512x512 est finie.

Modèle	Résolution native	Plage pratique
SD 1.5	512x512	512x512 à 768x768
SDXL	1024x1024	1024x1024 (standard), 1024x768, 768x1024
SD 3.5	1024x1024	1024x1024+
Flux	1024x1024	1024x1024+, 4K possible sur GPU haut de gamme

Dépasser la résolution native risque de produire des artefacts et des problèmes de composition. Utilisez plutôt hi-res fix ou l'upscaling au lieu de générer directement en 2048x2048.

Clip Skip

Moins pertinent qu'avant.

SD 1.5 : Clip skip 1-2 compte beaucoup. Les modèles anime utilisent souvent clip skip 2.
SDXL : Utilise deux encodeurs de texte (CLIP + OpenCLIP). Clip skip est largement ignoré -- l'architecture le gère différemment.
SD 3.5 / Flux : Pas applicable de la même manière. Ces modèles utilisent un encodage de texte basé sur des transformers.

Si vous êtes sur SDXL ou plus récent : ne vous préoccupez pas de clip skip. Si vous êtes sur SD 1.5 : gardez-le à 1 pour le photoréalisme, 2 pour l'anime.

Prompts négatifs

La philosophie s'est retournée. En 2023, le conseil était d'utiliser de longues listes de prompts négatifs. En 2026, le consensus est : commencez sans rien et n'ajoutez que ce dont vous avez besoin pour corriger.

Pourquoi ce changement :

SDXL et Flux comprennent le langage naturel bien mieux que SD 1.5
Les longs prompts négatifs peuvent en fait restreindre la créativité et produire de moins bons résultats
"bad anatomy" est trop vague pour être utile. "ugly" ne fonctionne pas parce que SD n'a pas été entraîné sur des images étiquetées "ugly"
Certains modèles donnent des résultats nettement pires avec de longs négatifs [5]

Approche actuelle :

Générez d'abord sans aucun prompt négatif.
Si vous voyez un problème précis (doigts en trop, arrière-plan flou), ajoutez un négatif ciblé pour celui-ci.
Utilisez la pondération d'emphase : (blurry:1.3) au lieu de simplement blurry.
Gardez-le court -- 5 à 10 termes au maximum.

Référence rapide GPU

GPU	VRAM	Bien pour
RTX 3060 12GB	12GB	SD 1.5, SDXL de base
RTX 4070 Ti	12GB	SDXL, un peu de Flux
RTX 4090	24GB	Tout. La machine de travail
RTX 5090	32GB	Tout, y compris la 4K et la génération par lots
Cartes 8GB	8GB	Minimum viable. ComfyUI aide à gérer la VRAM

Le seuil des 24 Go est celui où les choses deviennent confortables pour SDXL et Flux sans jongler constamment avec la VRAM.

Correctifs rapides de dépannage

Problème	À essayer
Sortie floue	Augmentez les étapes. Vérifiez que la résolution correspond à la résolution native du modèle
Doigts/membres en trop	Ajoutez `extra fingers, extra limbs` au prompt négatif. Ou utilisez ControlNet
Couleurs sursaturées	Baissez le CFG. Passez à DPM++ 2M Karras
La composition est mauvaise	Utilisez ControlNet (depth, canny, pose) au lieu de vous battre avec le prompt
La génération est lente	Utilisez un modèle Lightning, réduisez les étapes, utilisez ComfyUI pour une meilleure VRAM
Manque de VRAM	Passez à ComfyUI, réduisez la taille du batch, utilisez fp16

Références

1. Flux 2 and NVIDIA RTX AI Integration -- Article NVIDIA sur Flux 2 avec ComfyUI.
2. Stability AI Release Notes -- Dépréciation de SD 3.0 et sortie de 3.5.
3. SDXL-Lightning by ByteDance -- Génération en 2 à 8 étapes à 1024 px.
4. ComfyUI vs Automatic1111 2026 Comparison -- Comparaison des performances et des fonctionnalités.
5. How to Use Negative Prompts Effectively -- Guide mis à jour sur la philosophie des prompts négatifs minimaux.
6. Understanding Stable Diffusion Samplers -- Guide de comparaison et de sélection des samplers.
7. Best Stable Diffusion Models for 2026 -- Panorama actuel des modèles.

À propos

Thu, 04 May 2023 22:12:03 GMT

Les pages À propos sont une chose étrange à écrire. On finit par se décrire comme un étranger, et cela me rend méfiant.

Donc, simplement. Je suis Boris. J'écris du logiciel depuis un peu plus de quatorze ans. Le travail paie le loyer, nourrit les chiens et me donne presque chaque matin un problème à ronger — ce qui, honnêtement, est déjà plus que ce que font la plupart des métiers. Ces jours-ci, je suis la moitié backend d'une petite équipe produit, quelque part entre Laravel, Docker et Kubernetes, surtout préoccupé par des files d'attente qui devraient se vider plus vite qu'elles ne se remplissent et par des index qui grossissent plus vite que je ne voudrais.

Avant le logiciel, j'ai étudié les mathématiques à l'université. Je n'ai jamais vraiment arrêté. Les mathématiques sont l'endroit où je vais quand le monde devient trop bruyant. La théorie des nombres surtout — il y a quelque chose d'honnête dans un nombre premier que je ne retrouve pas dans beaucoup d'autres endroits. Une grande partie de ce que j'écris ici part de là. Une petite démangeaison mathématique. Un article médical à moitié compris. Une phrase française qu'il m'a fallu lire quatre fois. Puis je tire dessus et je regarde ce qui vient avec.

Le blog est l'endroit où cela se passe. Rien de tout cela n'est un travail d'expert. Je lis de la médecine que je n'ai aucune raison de lire. Je lis des romans bulgares et français et je fais semblant de suivre. J'apprends l'allemand lentement, surtout parce que la grammaire m'amuse. Il m'arrive d'écrire du C++ à la main. Pas pour le travail — simplement parce que la discipline est une chose en soi. Les essais sortent de tout cela — de tranquilles tentatives de noter ce que j'ai remarqué avant de l'oublier.

Je vis à Sofia. Deux chiens errants recueillis — Кожухка et Еклер — veillent à ce que je ne me prenne pas trop au sérieux. Ils ont déjà échoué. Ils continuent d'essayer.

C'est à peu près tout. Je garde une petite enseigne de freelance sous le nom de Percepticus, pour les travaux qui arrivent par bouche à oreille. Sinon, les essais sont ici, et cela me convient de rester discret sur le reste.

Accueil - Boris D. Teoharov (Français)

Ivoire sous l'ambre

Quand le compteur apparaît

Les gens que j’aime ont le droit d’être humains

Je peux être bienveillant sans disparaître

Le pilier et le lierre

Un pilier dans un champ

Le professeur a oublié le lierre

Où vous allez continuer à le rencontrer

Un pilier qu'on peut serrer dans ses bras

Une petite fin

Là où toutes les sciences se rejoignent

Le langage est un code de très haut niveau

La porte qui ne s'ouvre pas de l'intérieur

Alignement mutuel

Le cerveau n'est pas paresseux

La Bulgarie parle

L'ingénierie, mais honnêtement

L'excellence, c'est la marche

Si tu ne peux pas l'expliquer à un enfant

Là où toutes les sciences se rejoignent

La petite fin

Le modèle qui n'était pas là

La ville qui n'était pas là

La file qui ne s'est jamais arrêtée

L'option nucléaire pour les suppressions massives : TRUNCATE + réinsertion (MySQL/InnoDB)

Pourquoi DELETE reste lent (même par lots)

L'option nucléaire : TRUNCATE + réinsertion

Pourquoi c'est rapide

Quand l'utiliser (et quand ne pas l'utiliser)

Utilisez-la quand

Ne l'utilisez pas quand

Une règle de décision pratique

Implémentation (SQL)

Implémentation (Laravel/PHP)

Les pièges à prévoir absolument

Réinitialisation de l'auto-increment

Clés étrangères

Triggers

Espace disque

Réplication / binlog

Si vous avez besoin d'un downtime (presque) nul

Dernière pensée

Refactoring de type 0 : l'étape avant la première étape

La vraie raison d'être du type 0 : les humains ont un budget de mémoire de travail

Pourquoi l'appeler "type 0"

Le probleme que le type 0 resout

Utilisez le type 0 quand...

Une définition que vous pouvez utiliser dans votre équipe

Pourquoi le nommer ?

Les quatre sous-patterns

0a. Extraction de méthodes (la fondation)

0b. Concision (réduire la complexité incidente)

0c. Empathie (lisibilité pure)

0d. Suppression du code mort (retirer les mensonges)

Ce que le type 0 n'est pas

La promesse centrale : préservation du comportement (et comment la garder vraie)

Le type 0 comme rituel d'équipe répétable

1) Décider le périmètre (un timebox aide)

2) Identifier la "colonne vertébrale" du code

3) Appliquer les quatre sous-patterns dans l'ordre

4) Garder une "checklist type 0" dans votre PR

Pensée de clôture

Lavez une assiette de plus : une règle simple pour une base de code toujours propre

La métaphore : cuisine, assiettes et code

Échos du métier : vous êtes en bonne compagnie

Pourquoi l'assiette en plus compte (même quand vous êtes occupé)

1. L'entropie est réelle

2. La dette compose plus vite que vous ne le pensez

3. Le signal social

4. De l'élan, pas du perfectionnisme

Comment pratiquer la règle Lavez-une-assiette-de-plus

1. Adoptez le "micro-refactoring" comme critère de terminé

2. Utilisez les pull requests comme déclencheur de nettoyage

3. Automatisez les assiettes faciles

4. Inscrivez-la dans les normes de l'équipe

5. Sachez quand ne pas laver

La limite : une assiette, pas l'évier

Exemple : transformer une fonction confuse en fonction testable

Dernières pensées

Pourquoi `DELETE` reste lent (même par lots)

1. Pipe Operator (`|>`) – « Easy Peasy Lemon Squeezy »

2. `#[\NoDiscard]` – L'intention militarisée

4. `php --ini=diff` – Rayon X de dérive de config

6. `array_first()` / `array_last()` – L'évidence existe enfin

7. `get_exception_handler()` (et meilleures traces fatales) – Upgrade d'observabilité