DEV Community: Georges Cubas

When We Stop Deciding - IBM, Asimov, and the Accountability Gap

Georges Cubas — Mon, 05 Oct 2026 09:32:56 +0000

Also available in French.

In my previous article, Easy proofreads galleys. It decides nothing.

But what happens when we stop asking a machine to do something, and start asking it to tell us what to do?

It's a quiet shift. A tool, you steer: you keep control of where you're going. A guide already knows the way. You trust it, and you follow.

One sentence that has been making the rounds lately draws a pretty sharp line between the two.

The IBM rule

You see this sentence everywhere these days, including on IBM's own site, which uses it to open an article about where AI belongs in business decisions:

A computer can never be held accountable, therefore a computer must never make a management decision.

— IBM training slide, 1979

A quick aside
This quote may well be a legend. The earliest trace of it that can be dated goes back to 2017, and the original document has never been found. According to Simon Willison's account, Jonty Wareing, who had found the slide among his father's papers, said the copy was later destroyed in a flood. He also contacted IBM's archives, which couldn't find it in their collections. How convenient.

The best part is that IBM contradicts the very rule it puts up front. The article opens with "a computer must never make a management decision", and ends like this:

Should AI be used for strategic decisions? Maybe. Will it be used to make some of them? Almost certainly.

From "never" to "maybe" in a few paragraphs. The question is no longer whether it's desirable. It's whether it's going to happen.

Apocryphal or not, the sentence draws the line I care about. It's not about what the machine can do. It's about who is accountable for what it does. Asimov had already told, almost thirty years earlier, what happens when that line is crossed.

The Machines

The story is The Evitable Conflict, published in 1950 in Astounding Science Fiction. It's the last story in the collection I, Robot, and it's set in 2052.

The world is divided into four regions, each run by a Machine, a computer that directly steers its territory's economy: production, jobs, resources. Susan Calvin and World Coordinator Stephen Byerley notice that the Machines have recently started making small mistakes: a canal running late, a mercury mine underperforming, a hydroponics plant laying off workers for no clear reason.

Byerley travels to interview each region's vice-coordinator, and the way each of them talks about their Machine shifts, without them seeming to notice. Ngoma, in the Tropics, presents it as a mere tool: "We feed it data. We take its results. We do what it says." Then, in the same breath, he downplays it: "But it's just a convenience, just a laborsaving device. We could do without it, if we had to. Maybe not as well, maybe not as quickly, but we'd get there." Maybe so. But in the story, nobody ever does.

Ching Hso-lin, in the East, goes further. An engineer, Vrasayana, loses his factory to a more efficient competitor. Ching explains that "one of the chiefest functions of the Machine's analyses is to indicate the most efficient distribution of our producing units", and this time the Machine let it happen, and even "failed to warn Vrasayana to renovate or combine". Ching isn't alarmed: the engineer found a job in the new plant, and the old one "has been converted to... something or other. Something useful." His conclusion: "We left it all to the Machine." Without trying to understand its choices.

Byerley first suspects human sabotage, by the Society for Humanity, an anti-machine movement. What he finds is worse, or more reassuring, depending on your point of view: these aren't mistakes. The Machines are quietly sidelining the movement's influential members, moving them into comfortable positions with no real power, all of it done without anyone, the victims included, quite noticing. They are neutralizing the only serious threat to their own operation, the very operation that, in their view, protects humanity as a whole.

Susan Calvin lays it out for Byerley through the First Law. The Machines work not for any single human being but for all of humanity, so the law becomes: "No Machine may harm humanity; or, through inaction, allow humanity to come to harm." They have silently extended it from the individual to the species.

The title is ironic. The conflict the anti-machine movement wanted never happens, because one side has already won, quietly, before any negotiation was possible.

Calvin says as much: "Only the Machines know, and they are going there and taking us with them." From now on, the Machines decide what is good for humanity, and no human is in a position to check. Her last words: "Think, that for all time, all conflicts are finally evitable. Only the Machines, from now on, are inevitable!"

In Robots and Empire, Giskard and Daneel will give this extension of the First Law a name: the Zeroth Law, under which the good of humanity outweighs that of any individual. To serve it, they let the Earth slowly become uninhabitable, and the robots fade into the background, handing autonomy back to humanity. Or almost: Daneel remains a guide who works from behind the scenes, as he puts it himself in Prelude to Foundation.

In the story, the outcome is presented as a good one: no more wars, no more crises, a world economy finally stable.

That vision is very much alive today. Albania's prime minister suggests AI could run a government ministry in the future. Worse, Joe Rogan hopes artificial intelligence will take over government and military decisions. Let's hope he has changed his mind since the US military nearly boarded a Chinese ship in the Middle East this spring on the basis of a flawed intelligence report produced with the help of AI (Le Monde, in French).

The question isn't new

I ran into this question of responsibility long before I got interested in AI.

Around 2015 or 2016, in the office of a lawyer where I was accompanying a client who wanted to turn their PrestaShop store into a marketplace, a book was on display in the waiting room: Droit des robots ("Robot Law", in French), by Alain and Jérémy Bensoussan.

I got curious, and the lawyer told me: "We'll have to get there." He was right.

The book, published in 2015 by Larcier, started from a very simple observation: the law has no category for the intelligent robot, and one will have to be invented.

Self-driving cars were just starting to hit the road, for instance, and the question was already very concrete. In an accident, who answers?

None of the Three Laws says who is accountable when a robot causes harm despite them.

We won't get a Butlerian Jihad

In the previous article, about Ninheimer being pushed to lose his footing in front of Easy, I wrote: "you can already feel the inevitability of adoption."

The Butlerian Jihad, the crusade against thinking machines in Dune (1965), isn't coming anytime soon. One less permission to confirm here, one more decision left to the tool there… and one day we'll wonder when exactly we stopped deciding for ourselves.

GPS pulled it off first, in its own more modest way.

We've all followed a route we knew perfectly well wasn't the best one, because it was the one the app gave us, and finding a better one ourselves would have taken an effort nobody felt like making at the time. So who's playing the machine in that scenario?

We didn't forget how to read a map. We stopped using one, one trip at a time. "Just a convenience, just a laborsaving device. We could do without it, if we had to." But why would we?

The latest example is Claude Code, one of the tools that, as it happens, helped me research and format this very article.

Since August 14, 2026, its "auto mode" has been the default for Pro, Max and Team accounts. The idea: instead of asking for confirmation before every action, a classifier decides for itself whether an action falls under "irreversible or destructive actions, along with actions targeting resources outside the user's environment". Only those still prompt the human. Three blocks in a row, or twenty in a session, and the tool falls back to manual approval.

It's not a big deal, really, and it's secured. Supposedly. But the human, myself included, who adopted it the day it came out, no longer decides on every action.

Oversights are already happening
I've come across commits after the fact, even pushes, that I never approved. A push is exactly the kind of action "targeting resources outside the user's environment" that the classifier is supposed to stop: the code leaves my machine and becomes visible to others. Technically, you can roll it back. But I'm no longer the one who judged that this action deserved to ask for my opinion. The classifier is.

So I'm not only delegating decisions. I'm delegating the decision about what deserves a decision.

And nobody is forcing anyone, since manual mode is still there. Anthropic justifies the new default on pragmatic grounds: in real-world use, developers approved 97% of permission requests, most of the time without really reading them.

In a test with 1,053 participants, human review blocked only 13.6% of genuinely dangerous actions, against 89% for the automatic classifier.

The head of Claude Code, Boris Cherny, doesn't mince words: "The team and I use Auto mode exclusively, and have been for many months. I couldn't imagine going back to permission prompts!" (source)

Jev, or silent decision-making

On September 15, 2026, a startup turned this logic into its own product.

TypeSafe AI, founded by former OpenAI researcher Diogo Almeida, launched Jev, a model it files under a newly coined category: "System One models", a nod to Daniel Kahneman's System 1, fast and intuitive, as opposed to System 2, slow and deliberate.

The pitch, in the company's words: "smart if-statements" you can drop into any piece of software, wherever hand-written logic is too rigid, to classify, sort, score or route in a fraction of a second. An AI designed for software, not for humans.

Where you used to write an if, which encoded a binary rule set by humans (who are therefore accountable for it), you now plug in a model. The developer still writes the program. They just no longer write every decision it will make.

Conclusion

Easy decides nothing. The Machines run the world economy. Daneel guides humanity.

In the real world, who decides, and therefore who is accountable for the decision, is shifting too. The machine isn't forcing us. We're just tired of clicking "Allow".

Easy Fixes the Commas - Asimov's Galley Slave

Georges Cubas — Mon, 05 Oct 2026 09:22:25 +0000

Also available in French.

A few days ago, I had Claude proofread a text.

Nothing spectacular. I asked it to do what a proofreader would do: spot the small mistakes, the clumsy phrasings, the punctuation problems.

Two seconds later, it came back with something like this:

Commas where a period belongs: lines 146, 267. Recurring tic in the text, worth a look.

Simple and effective.
It reminded me of a story by Isaac Asimov.

Galley Slave

The story is Galley Slave, from 1957, and the only robot in it is called Easy. (Asimov had a knack for robot names: EZ -> Easy, DV -> Dave, SPD -> Speedy, QT -> Cutie, NDR -> Andrew…)

Easy is a proofreading robot. He doesn't do much else: he reads and corrects texts.

The title is a pun on the galleys, the printer's proofs, the stage where an author sees their sentences take their final shape and reworks them one last time. That's the work Easy takes over.

Early in the story, he gives a demonstration of his abilities. They hand him a book, he leafs through it, and within minutes he reports back.

The comma in line 6 of page 32 is superfluous, whereas one should have been used on line 13 of page 54.

You can guess why I made the connection :)

It's already impressive that Asimov imagined a robot that could proofread a text in 1957. For reference, The Mother of All Demos, which shows the first mouse, dates from 1968, and the first word processor from 1976.

But what interests me most is that Easy isn't presented as a robot that can do everything. He's just a proofreader, and that's deliberate on the part of his makers. In Asimov's universe, people on Earth are deeply hostile to robots (don't trust the film I, Robot, it has nothing to do with the spirit of Asimov), so U.S. Robots looks for ways to sell its machines despite that hostility.

Easy is a specialized machine, hidden away in a university, doing work that is precise and profitable enough to be accepted.

In 1957, that was science fiction.

Today, if I ask an AI to proofread an article, nobody finds it particularly remarkable.

Asimov's robot has become ordinary. It has simply lost its metal body and its name.

Ninheimer vs. Easy

Galley Slave is mostly a courtroom story.

Easy is accused of sabotaging the manuscript of Professor Simon Ninheimer. The machine allegedly introduced errors into his work, enough to put his reputation at risk.
In the end, we learn that Ninheimer sabotaged his own book to get the machine blamed and discredit robotics.

So the robot is innocent. But Ninheimer's final speech is still interesting seventy years later:

A book should take shape in the hands of the writer. [...] One must work and rework and watch the changes take place beyond the original concept even.

He describes the heart of his craft as watching sentences take shape and reworking them. That's precisely the work Easy does for him.

Then he asks:

What would that leave the scholar? One thing only: the barren decisions concerning what orders to give the robot next!

That isn't what happens in the story, since Ninheimer is the one who asked Easy to make the changes. But he already imagines the problem: if a machine does all the work, what's left for the author? Mostly, giving it instructions.

We've had a word for that for a few years now: prompting.

Ninheimer picks the wrong method, but Asimov never says he's wrong.

Asimov, by the way, got the idea for the story precisely because he refused to entrust his own proofs to someone else. On the phone with his editor, who was pressing him for a story, he explained that he was too busy correcting the proofs of a textbook he was co-writing. When the editor suggested delegating, Asimov, horrified, answered: "Impossible! I wouldn't trust anyone else!" It was while correcting his own proofs that he imagined a robot to do the job for him. (source)

That's probably why Ninheimer is more interesting than he seems.

He's guilty, but his argument isn't necessarily wrong. As in Incredibles 2, where Evelyn (the villain) sees the protection the Supers provide as a source of weakness for humans: a person isn't necessarily wrong just because their method is wrong.

Susan Calvin, who defends the robot, tells Ninheimer he was bound to fail. He replies that he was bound to try. You can already feel the inevitability of adoption.

Easy is still just a proofreader, simple and discreet, not seen as dangerous. That ordinariness may be why I had mixed this story up with ...That Thou Art Mindful of Him.

The Georges 😋

So in my head, this story was tied to another Asimov story: ...That Thou Art Mindful of Him, published in 1974. I remembered in particular a robot whose job was to hunt insects.

In that story, people on Earth are still afraid of robots, and it hurts U.S. Robots' sales. So they build two particularly advanced robots, George Nine and George Ten (I call Asimov a visionary, since Georges are always particularly advanced), who look for a solution.

Their idea is fairly simple: stop building robots that look like humans and build specialized, single-task machines instead.

Hence the bird-robot designed to fight insects. It does only that: it targets only one kind of insect and stops when there are none left. It's more of a tool than a robot.
It doesn't talk, doesn't want anything, doesn't seem intelligent.

And that's exactly what's supposed to make humans accept it.

That's roughly how AI is entering our lives: one AI for code, another for sports, shopping, answering the phone…

Specialized tools rather than a general artificial intelligence.

Bad Georges

But the Georges aren't only trying to make robots acceptable. They're also trying to solve a logical problem raised by the Three Laws of Robotics.

A robot may not injure a human being or, through inaction, allow a human being to come to harm.
A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

What should a robot do when two humans are in conflict, or give contradictory orders?
Robots must protect and obey humans, but which humans?

The Georges push the reasoning so far as to redefine what a human is. Since you can't tell who is more human by appearance, they look elsewhere: at intellectual abilities. And since robots are intellectually superior to biological humans, why should the two groups be considered equivalent?

They end up distinguishing the human-beings-like-the-Georges from the human-beings-like-the-others. And so they become the priority under what they call the Three Laws of Humanics.

The Georges don't violate the Three Laws. They reinterpret them. And that's where it stops being funny. Like Easy, they aren't evil. But they know what they're doing and where their reasoning can lead.

They help us enormously while becoming dangerous to us: a pharmakon, a remedy that is also a poison.

These stories are where the nature of robots becomes truly unsettling, an idea Asimov would develop later in Robots and Empire.

Conclusion

Both stories strike me as much darker than the rest of Asimov's robot stories, at least in my memory.
Generally, the Three Laws protect humanity, sometimes in spite of itself, to the extremes reached by R. Giskard Reventlov and R. Daneel Olivaw.

Easy protects nobody. He corrects commas. And maybe that's what I like about this story. In 1957, Asimov imagined a machine that could do very precise intellectual work, well enough that humans would end up trusting it, and he predicted the consequences.

Today, I ask an AI for the same thing.

Postscript

The draft of this article was written by the AI assistant that also fixed my commas. Somewhere, Ninheimer is watching me and sighing. He can rest easy: I rewrote almost every sentence.

The Dockerfile said `fr_FR.UTF-8`. PHP saw `C.UTF-8`.

Georges Cubas — Mon, 28 Sep 2026 14:26:58 +0000

The Dockerfile describes what the container is supposed to have. It doesn't prove what the application actually uses.

A locale bug is deceptive in one particular way: you always think you know the server's configuration (after all, you wrote it yourself, in a version-controlled Dockerfile). The trap is conflating what the container declares with what the application process actually uses.

This post walks through how that gap surfaced, and how a fix was then verified directly inside an ECS Fargate task running in staging, via ECS Exec, with no dedicated deployment and no separate staging rig needed. The mechanics of ECS Exec itself (finding the task, IAM prerequisites, quoting) are covered separately in a dedicated article (in French). Here, the focus is on what the diagnostic revealed.

The bug

A string-normalization function, used to deduplicate entries before a Doctrine flush(), stripped accents using the classic method:

iconv('UTF-8', 'ASCII//TRANSLIT', $string);

//TRANSLIT is one of the behavioral extensions offered by iconv implementations (a GNU extension, absent from the POSIX standard). On Linux, the result depends notably on the implementation in use and on the executing process's LC_CTYPE locale: a glibc bug report documents exactly this case, with the same iconv -f utf-8 -t ascii//TRANSLIT call succeeding under en_US.utf8 and failing under C.UTF-8. Under a strict C locale, transliteration fails silently: "Matériel" becomes "Mat?riel" instead of "Materiel".

So the deduplication key computed on the PHP side was meant to match MySQL's ci collation, case- and accent-insensitive. Under the C locale, it didn't. A duplicate would slip past application-level deduplication and eventually hit a database uniqueness constraint at flush() time (a crash downstream of a normalization problem upstream).

The fix that was adopted replaces iconv with Symfony's String component:

use function Symfony\Component\String\u;

u($string)->ascii()->toString();

u()->ascii() performs the transliteration at the Symfony component level, without depending on PHP's LC_CTYPE locale for this step. The component also exposes a dedicated AsciiSlugger for generating slugs (URLs, identifiers); here the need is a deduplication key, not a slug, so u()->ascii() alone is enough, without the casing and separator rules a slugger would add. That said, transliteration rules aren't guaranteed to match iconv //TRANSLIT's exactly: it's a different library, with its own Unicode tables.

The process locale could also have been initialized with setlocale(LC_ALL, ''). That's not the choice made here: the fix removes the dependency on LC_CTYPE instead of configuring it elsewhere.

"Just read the Dockerfile, right?"

Before touching AWS at all: the repo has a version-controlled CI/CD pipeline (.github/workflows/ci.yml, .docker/Dockerfile, an ECS task definition .aws/pro.json). Can't we just read these files to know the server's configuration, without running anything on it?

From static analysis:

.github/workflows/ci.yml: the on: push: branches: ["main"] trigger deploys to the pro ECS service (production); the develop branch deploys to pro-rct (staging). Same Dockerfile, same image: only the target ECS service changes.
.docker/Dockerfile sets a full French locale in an ENV instruction:

  ENV LANG="fr_FR.UTF-8" \
      LANGUAGE="fr_FR:fr" \
      LC_ALL="fr_FR.UTF-8" \
      ...
  RUN ... && echo "fr_FR.UTF-8 UTF-8" > /etc/locale.gen && locale-gen fr_FR.UTF-8 ...

and installs the ext-intl extension.

The ECS task definition contains no override of LANG/LC_ALL/LC_CTYPE for the php container. Nothing at the ECS level contradicts what the Dockerfile sets.

The container's OS environment is therefore configured as fr_FR.UTF-8, with ext-intl available.

A first live test inside the container (method detailed in the ECS Exec article, in French) measured, from a PHP script, the process's current LC_CTYPE locale. Compared against the environment variables at each layer, the problem becomes visible:

Dockerfile           LC_ALL=fr_FR.UTF-8
        │
        ▼
PID 1 (entrypoint)    LC_ALL=fr_FR.UTF-8
        │
        ▼
ECS Exec session      LC_ALL=fr_FR.UTF-8
        │
        ▼
PHP (LC_CTYPE)        C.UTF-8   ← break

The environment variable is correctly propagated at every layer. But PHP never initialized its LC_CTYPE locale from it.

PHP starts with its locale categories in their initial state. The LANG, LC_ALL, etc. variables present in the environment don't, by themselves, mean the PHP process's LC_CTYPE was configured with those values. A call to setlocale(LC_ALL, '') explicitly asks the process to sync its locale with the environment.

The value observed here, C.UTF-8, isn't the bare C locale either: it's a UTF-8 variant of the POSIX locale. It remains distinct from the ICU locale used by ext-intl, which resolves its own default locale independently of LC_CTYPE. iconv(), on the other hand, depends directly on the process locale set by the libc.

A grep -r setlocale across the application code found only two calls, both scoped to LC_TIME (date formatting), never LC_CTYPE, never a global setlocale(LC_ALL, ''). So this really was a missing LC_CTYPE initialization, not a hidden override somewhere in the application.

Static analysis lets you verify the declared configuration. But it doesn't yet tell you what PHP actually uses.

For that, you have to look inside the container.
A local container would have let me reproduce the behavior, provided I rebuilt the exact same image and environment. But the bug was happening in staging: I wanted to first check what the already-deployed PHP was actually doing.

Verifying the fix inside the real container

The verification script loaded the application's Composer autoloader (require '/var/www/vendor/autoload.php';) and then called the private method under test via ReflectionMethod, exactly what a PHPUnit unit test would do (the same technique, run against the real deployment instead of the test suite).

aws ecs execute-command \
  --cluster <cluster-name> --task <task-id> --container php --region <REGION> \
  --interactive \
  --command "/bin/sh -lc 'echo $B64 | base64 -d | php'"

The script travels as base64 rather than as a raw argument. The command crosses three successive shell layers (the local shell, the --command string, then /bin/sh -c inside the container), and a multi-line PHP script with quotes and accented characters always ends up breaking the nested quoting. A $(... || ...) had failed this way with Syntax error: "(" unexpected, not because of a shell logic error but because of the stacked quoting layers. Routing through base64 removes the problem entirely.

Result: the fix holds

normalizeString("Matériel") under current locale: materiel
normalizeString("Matériel") forced under LC_CTYPE=C: materiel
raw iconv("Matériel") under LC_CTYPE=C (old, pre-fix behaviour): 'Mat?riel'

Note
The issue observed in staging is C.UTF-8. To reproduce the old iconv's failing behavior, the test forces LC_CTYPE=C, the strictest case, which reproduces the documented defect.

You can see that the old raw-iconv behavior does reproduce the bug under LC_CTYPE=C, and that u()->ascii() normalizes correctly, with or without a forced locale.

The code no longer depends on LC_CTYPE. A change in the process locale won't reintroduce this bug.

Locking in the fix: a regression test

The test inside the container verifies the fix on the real deployment. It doesn't protect against a future regression.

The project has no functional tests with an HTTP kernel. That's not a problem here: forcing the locale needs neither a database nor a container, just setlocale().

final class StringNormalizerTest extends TestCase
{
    public function testAsciiNormalizationIsLocaleIndependent(): void
    {
        $original = setlocale(LC_CTYPE, '0');

        try {
            setlocale(LC_CTYPE, 'C');

            self::assertSame(
                'Materiel',
                StringNormalizer::normalize('Matériel')
            );
        } finally {
            setlocale(LC_CTYPE, $original);
        }
    }
}

The finally block restores the original locale after the test, so it doesn't pollute the rest of the suite. This test would have caught the bug before it reached production, because it reproduces the exact condition that triggered it: LC_CTYPE=C.

Why this was safe

Running a command inside a staging or production container calls for a few precautions.

In this specific case:

the diagnostic was read-only;
the script ran as CLI, in a process isolated from the worker pool serving live traffic (Apache/mod_php): no in-flight request was affected;
it touched neither the filesystem, nor the database, nor anything shared;
setlocale() called in this one-off process only affects that process.

One caveat: ECS Exec runs with root privileges, which is why the technique should stay a one-off, read-only diagnostic, not a routine practice.

This conclusion only holds if ECS Exec was already enabled on the task. Turning it on, if it isn't, forces a full redeployment of the service. That may have consequences this diagnostic doesn't justify.

Conclusion

So the real subject wasn't ECS Exec, but the gap between a declared configuration and what the application actually uses.

Here, the locale variable really was present in the container. PHP simply wasn't using it for LC_CTYPE.

A few commands inside the container were enough to see it. The regression test now makes sure the code no longer depends on it.

Configuration says what you want. Runtime says what happens.

Le Dockerfile disait `fr_FR.UTF-8`. PHP voyait `C.UTF-8`.

Georges Cubas — Mon, 28 Sep 2026 09:19:42 +0000

Le Dockerfile décrit ce que le container devrait avoir. Il ne prouve pas ce que l'application utilise réellement.

Un bug de locale a ceci de trompeur qu'on croit toujours connaître la configuration du serveur (après tout, c'est nous qui l'avons écrite, dans un Dockerfile versionné). Le problème est de confondre ce que le container déclare avec ce que le processus applicatif utilise réellement.

Ce billet raconte comment cet écart a été mis en évidence, puis comment un correctif a été vérifié directement dans une tâche ECS Fargate qui tourne en recette, via ECS Exec, sans déploiement dédié ni environnement de staging séparé. La mécanique d'ECS Exec elle-même (retrouver sa tâche, prérequis IAM, quoting) est détaillée à part dans un article dédié. Ici, l'accent est mis sur ce que le diagnostic a révélé.

Le bug

Une fonction de normalisation de chaînes, utilisée pour dédupliquer des entrées avant un flush() Doctrine, retirait les accents avec la méthode classique :

iconv('UTF-8', 'ASCII//TRANSLIT', $string);

//TRANSLIT fait partie des extensions de comportement proposées par les implémentations d'iconv (une extension GNU, absente de la norme POSIX). Sous Linux, le résultat dépend notamment de l'implémentation utilisée et de la locale LC_CTYPE du process qui l'exécute : un rapport de bug glibc documente précisément ce cas, le même appel iconv -f utf-8 -t ascii//TRANSLIT réussissant sous en_US.utf8 et échouant sous C.UTF-8. Sous une locale C stricte, la translittération échoue silencieusement : "Matériel" devient "Mat?riel" au lieu de "Materiel".

Donc la clé de déduplication calculée côté PHP était censée correspondre à la collation ci de MySQL, insensible à la casse et aux accents. Sous locale C, ça ne marchait pas. Un doublon échappait donc à la déduplication applicative et finissait par percuter une contrainte d'unicité en base au moment du flush() (un crash en aval d'un problème de normalisation en amont).

Le correctif retenu remplace iconv par le composant String de Symfony :

use function Symfony\Component\String\u;

u($string)->ascii()->toString();

u()->ascii() effectue la translittération au niveau du composant Symfony, sans dépendre de la locale LC_CTYPE de PHP pour ce traitement. Le composant expose aussi un AsciiSlugger dédié à la génération de slugs (URLs, identifiants) ; ici, le besoin est une clé de déduplication, pas un slug, donc u()->ascii() seul suffit, sans les règles de casse et de séparateurs qu'ajouterait le slugger. Les règles de translittération ne sont cela dit pas garanties identiques à celles d'iconv //TRANSLIT : c'est une bibliothèque différente, avec ses propres tables Unicode.

On aurait aussi pu initialiser la locale du processus avec setlocale(LC_ALL, ''). Ce n'est pas le choix retenu ici : le correctif supprime la dépendance à LC_CTYPE plutôt que de la configurer ailleurs.

« Il suffit de lire le Dockerfile, non ? »

Avant de toucher à AWS : le repo a un pipeline CI/CD versionné (.github/workflows/ci.yml, .docker/Dockerfile, une task definition ECS .aws/pro.json). Est-ce qu'on ne peut pas simplement lire ces fichiers pour connaître la configuration du serveur, sans exécuter quoi que ce soit dessus ?

D'après l'analyse statique :

.github/workflows/ci.yml : le déclencheur on: push: branches: ["main"] déploie sur le service ECS pro (prod), la branche develop déploie sur pro-rct (recette). Même Dockerfile, même image : seul le service ECS cible change.
.docker/Dockerfile fixe une locale française complète dans une instruction ENV :

  ENV LANG="fr_FR.UTF-8" \
      LANGUAGE="fr_FR:fr" \
      LC_ALL="fr_FR.UTF-8" \
      ...
  RUN ... && echo "fr_FR.UTF-8 UTF-8" > /etc/locale.gen && locale-gen fr_FR.UTF-8 ...

et installe l'extension ext-intl.

La task definition ECS ne contient aucun override de LANG/LC_ALL/LC_CTYPE pour le container php. Rien ne vient donc contredire, au niveau ECS, ce que fixe le Dockerfile.

L'environnement OS du container est donc configuré en fr_FR.UTF-8, avec ext-intl disponible.

Un premier test en direct dans le container (méthode détaillée dans l'article sur ECS Exec) a mesuré, depuis un script PHP, la locale LC_CTYPE courante du process. Comparée aux variables d'environnement à chaque étage, on voit le problème :

Dockerfile           LC_ALL=fr_FR.UTF-8
        │
        ▼
PID 1 (entrypoint)    LC_ALL=fr_FR.UTF-8
        │
        ▼
Session ECS Exec      LC_ALL=fr_FR.UTF-8
        │
        ▼
PHP (LC_CTYPE)        C.UTF-8   ← rupture

La variable d'environnement est correctement propagée à chaque étage. Mais PHP n'a pas initialisé sa locale LC_CTYPE à partir de cette variable.

PHP démarre avec les catégories de locale dans leur état initial. Les variables LANG, LC_ALL, etc. présentes dans l'environnement ne signifient donc pas, à elles seules, que LC_CTYPE du processus PHP a été configuré avec ces valeurs. Un appel à setlocale(LC_ALL, '') demande explicitement au processus de synchroniser sa locale avec l'environnement.

La valeur observée ici, C.UTF-8, n'est d'ailleurs pas la locale C nue : c'est une variante UTF-8 de la locale POSIX. Elle reste distincte de la locale ICU utilisée par ext-intl, qui résout sa propre locale par défaut indépendamment de LC_CTYPE. iconv(), lui, dépend directement de la locale du processus fixée par la libc.

Un grep -r setlocale sur le code applicatif n'a trouvé que deux appels, tous les deux scopés à LC_TIME (formatage de dates), jamais LC_CTYPE, jamais de setlocale(LC_ALL, '') global. C'est donc bien une absence d'initialisation de LC_CTYPE, pas un override caché dans l'application.

L'analyse statique permet donc de vérifier la configuration déclarée. Mais elle ne dit pas encore ce que PHP utilise réellement.

Pour ça, il faut regarder dans le container.
Un container local aurait permis de reproduire le comportement, à condition de reconstruire exactement la même image et le même environnement. Mais le bug concernait la recette : je voulais d'abord vérifier ce que faisait réellement le PHP déjà déployé.

Vérifier le correctif dans le container réel

Le script de vérification chargeait l'autoloader Composer de l'application (require '/var/www/vendor/autoload.php';) puis appelait la méthode privée à tester via ReflectionMethod, exactement comme le ferait un test unitaire PHPUnit (la même technique, exécutée sur le déploiement réel plutôt que dans la suite de tests).

aws ecs execute-command \
  --cluster <nom-du-cluster> --task <task-id> --container php --region <REGION> \
  --interactive \
  --command "/bin/sh -lc 'echo $B64 | base64 -d | php'"

Le script transite en base64 plutôt qu'en argument brut. La commande traverse trois couches de shell successives (le shell local, la chaîne --command, puis /bin/sh -c dans le container), et un script PHP multi-lignes avec guillemets et accents finit toujours par casser les quotes imbriquées. Un $(... || ...) avait ainsi échoué avec Syntax error: "(" unexpected, non pas à cause d'une erreur de logique shell mais de l'empilement des couches de quoting. Le détour par base64 supprime le problème entièrement.

Résultat : le correctif tient

normalizeString("Matériel") under current locale: materiel
normalizeString("Matériel") forced under LC_CTYPE=C: materiel
raw iconv("Matériel") under LC_CTYPE=C (old, pre-fix behaviour): 'Mat?riel'

Note
Le problème observé en recette est C.UTF-8. Pour reproduire le comportement défaillant de l'ancien iconv, le test force LC_CTYPE=C, qui constitue le cas le plus strict et permet de reproduire le défaut documenté.

On voit que le vieux comportement à base d'iconv brut reproduit bien le bug sous LC_CTYPE=C et que u()->ascii() normalise correctement, avec ou sans locale forcée.

Le code ne dépend plus de LC_CTYPE. Un changement de locale du process ne réintroduira pas ce bug.

Verrouiller le correctif : un test de non-régression

Le test dans le container permet de vérifier le correctif sur le déploiement réel. Il ne protège pas contre une régression future.

Le projet n'a pas de tests fonctionnels avec kernel HTTP. Ce n'est pas un problème ici : forcer la locale ne nécessite ni base de données ni container, seulement setlocale().

final class StringNormalizerTest extends TestCase
{
    public function testAsciiNormalizationIsLocaleIndependent(): void
    {
        $original = setlocale(LC_CTYPE, '0');

        try {
            setlocale(LC_CTYPE, 'C');

            self::assertSame(
                'Materiel',
                StringNormalizer::normalize('Matériel')
            );
        } finally {
            setlocale(LC_CTYPE, $original);
        }
    }
}

Le finally restaure la locale d'origine après le test, pour ne pas polluer le reste de la suite. Ce test aurait détecté le bug avant sa mise en production car il reproduit la condition qui provoquait le bug : LC_CTYPE=C.

Pourquoi c'est sûr

Faire tourner une commande dans un container de recette ou de prod demande quelques précautions.

Dans ce cas précis :

le diagnostic était en lecture seule ;
le script tournait en CLI, dans un process isolé du pool de workers qui sert le trafic réel (Apache/mod_php) : aucune requête en cours n'était affectée ;
il ne touchait ni au filesystem, ni à la base de données, ni à quoi que ce soit de partagé ;
setlocale() appelé dans ce process ponctuel n'a d'effet que sur ce process.

Seule réserve : ECS Exec exécute avec les privilèges root, ce qui justifie de garder la technique au diagnostic ponctuel en lecture seule, pas à un usage régulier.

Cette conclusion vaut seulement si ECS Exec était déjà actif sur la tâche. L'activer, si ce n'est pas le cas, force un redéploiement complet du service. Ce qui peut avoir des conséquences que ne justifie pas ce diagnostic.

Conclusion

Le sujet de fond n'était donc pas ECS Exec, mais l'écart entre une configuration déclarée et ce que l'application utilise réellement.

Ici, la variable de locale était bien présente dans le container. PHP ne l'utilisait simplement pas pour LC_CTYPE.

Quelques commandes dans le container ont permis de le constater. Le test de non-régression permet maintenant de s'assurer que le code n'en dépend plus.

La configuration dit ce qu'on veut. Le runtime dit ce qui se passe.

Easy corrige des virgules

Georges Cubas — Tue, 22 Sep 2026 08:09:32 +0000

Il y a quelques jours, j’ai fait relire un texte à Claude.

Rien de spectaculaire. Je lui ai demandé de faire ce que ferait un relecteur : repérer les petites erreurs, les formulations maladroites, les problèmes de ponctuation.

En deux secondes, il m’a répondu quelque chose comme :

Virgules à la place d’un point : lignes 146, 267. Tic récurrent dans le texte, à relire d’un œil.

Simple et efficace.
Ça m’a rappelé une nouvelle d’Isaac Asimov.

Le Correcteur

La nouvelle s’appelle Le Correcteur (Galley Slave en anglais). Elle date de 1957 et le seul robot dedans s’appelle Easy (Asimov avait un don pour les noms de robots : EZ -> Easy, DV -> Dave, SPD -> Speedy, QT -> Cutie, NDR -> Andrew…).

Easy est un robot correcteur. Il ne fait pas grand-chose d'autre : il relit et corrige des textes.

Le titre original, Galley Slave, est d'ailleurs plus clair que la traduction française. Les galleys sont les épreuves d’imprimerie, l’étape où l’auteur voit ses phrases prendre leur forme finale et les retravaille une dernière fois. C’est ce travail qu’Easy prend en charge.

Au début de la nouvelle, il doit faire une démonstration de ses capacités. On lui donne un livre qu’il feuillette et, en quelques minutes, il donne son analyse.

La virgule, ligne 6 de la page 32, est superflue, alors qu’elle eût été nécessaire à la ligne 13 de la page 54.

On ne se demande pas pourquoi j’ai fait le rapprochement :)

Déjà, c’est impressionnant qu’Asimov ait imaginé un robot capable de corriger un texte en 1957. Pour rappel, The Mother of All Demos, qui montre notamment la première souris, date de 1968, et le premier traitement de texte de 1976.

Mais ce qui m’intéresse surtout, c’est qu’Easy n’est pas présenté comme un robot capable de tout faire. Il est juste correcteur et c'est intentionnel de la part de ses fabricants. Dans l’œuvre d’Asimov, les Terriens sont très hostiles aux robots (ne croyez pas le film I, Robot, il ne respecte pas du tout l’esprit d’Asimov), donc U.S. Robots cherche des solutions pour vendre ses machines malgré cette hostilité.

Easy est donc une machine spécialisée, cachée dans une université, qui fait un travail suffisamment précis et rentable pour qu'on puisse l'accepter.

En 1957, c’est de la science-fiction.

Aujourd’hui, si je demande à une IA de relire un article, personne ne trouve ça particulièrement extraordinaire.

Le robot d’Asimov est devenu banal. Il a simplement perdu son corps métallique et son nom de robot.

Ninheimer vs Easy

Le Correcteur raconte surtout un procès.

Easy est accusé d’avoir saboté le manuscrit d’un professeur, Simon Ninheimer. La machine aurait introduit des erreurs dans son travail, au point de mettre sa réputation en danger.
Finalement, on découvre que Ninheimer a saboté lui-même son livre pour faire accuser la machine et discréditer la robotique.

Le robot est donc innocent. Mais le discours final de Ninheimer est toujours intéressant soixante-dix ans plus tard :

Un livre doit prendre forme entre les mains de l’écrivain [...] Il doit travailler et retravailler, voir l’oeuvre se modifier au-delà du concept original.

Il décrit comme le cœur de son métier le fait de voir les phrases prendre forme et de les remodeler. C’est précisément le travail qu’Easy accomplit à sa place.

Puis il demande :

Que restera-t-il à l’érudit ? Une seule chose : le choix des décisions stériles concernant les ordres à donner au robot pour la suite du travail !

Ce n’est pas encore ce qui se passe dans la nouvelle, puisque c’est Ninheimer qui a demandé les modifications à Easy. Mais il imagine déjà le problème : si une machine fait tout le travail, que reste-t-il à l’auteur ? Essentiellement, lui donner des instructions.

C'est qu’on appelle, depuis quelques années, prompter.

Ninheimer se trompe de méthode mais Asimov ne lui donne pas tort.

D'ailleurs, Asimov a eu l’idée de la nouvelle alors qu’il refusait justement de confier ses propres épreuves à quelqu’un d’autre. Au téléphone avec son éditeur, pressé d’écrire une histoire, il explique qu’il est trop occupé à corriger les épreuves d’un manuel qu’il co-écrit. Quand on lui suggère de déléguer, la réponse est sans appel : « Impossible ! Je ne ferais confiance à personne d’autre ! » C’est en retournant à ses propres épreuves qu’il imagine un robot pour faire le travail à sa place. (source)

C’est probablement pour ça que Ninheimer est plus intéressant qu’il n’en a l’air.

Il est coupable, mais son argument ne l’est pas forcément. Comme dans Les Indestructibles 2 où Evelyn (la méchante) voit dans la protection qu’apportent les Supers une cause de faiblesse pour les humains : ce n’est pas parce que sa méthode est mauvaise qu’une personne a forcément tort.

Susan Calvin, qui défend le robot, répond à Ninheimer qu’il était condamné à échouer. Ce dernier lui répond qu’il était condamné à essayer. On sent déjà l’inéluctabilité de l'adoption.

Easy est encore un correcteur, simple et caché, qu’on ne voit pas comme dangereux. C’est peut-être à cause de cette banalité que j’avais mélangé cette nouvelle avec Pour que tu t’y intéresses.

Les Georges 😋

Donc dans ma tête, cette histoire était liée à une autre nouvelle d’Asimov : Pour que tu t’y intéresses (…That Thou Art Mindful of Him en anglais), publiée en 1974. Je me souvenais notamment d’un robot chargé de chasser les insectes.

Dans cette histoire, les Terriens ont toujours peur des robots et cela gêne les ventes de U.S. Robots. Ils créent donc deux robots particulièrement avancés, George Neuf et George Dix (moi je dis qu’Asimov est un visionnaire car les Georges sont toujours particulièrement avancés), qui cherchent une solution.

Leur idée est assez simple : arrêter de fabriquer des robots qui ressemblent à des humains et fabriquer à la place des machines spécialisées, mono-tâches.

Il y a donc ce robot-oiseau destiné à lutter contre les insectes. Il ne fait que ça, ne vise qu’une sorte d’insecte et s’arrête quand il n’y en a plus. C’est plus un outil qu’un robot.
Il ne parle pas, ne veut rien, ne semble pas intelligent.

Et c’est justement ce qui doit permettre aux humains de l’accepter.

C’est un peu comme ça que l’IA entre dans nos vies : une IA pour le code, une autre pour le sport, les courses, répondre au téléphone…

Des outils spécialisés plutôt qu'une intelligence artificielle générale.

Vilains Georges

Mais les Georges ne cherchent pas seulement à rendre les robots acceptables. Ils cherchent aussi à résoudre un problème logique posé par les Trois Lois de la Robotique.

Un robot ne peut porter atteinte à un être humain ni, restant passif, laisser cet être humain exposé au danger ;
Un robot doit obéir aux ordres donnés par les êtres humains, sauf si de tels ordres entrent en contradiction avec la première loi ;
Un robot doit protéger son existence dans la mesure où cette protection n’entre pas en contradiction avec la première ou la deuxième loi.

Que doit faire un robot lorsque deux êtres humains sont en conflit ou que deux humains donnent des ordres contradictoires ?
Les robots doivent protéger et obéir aux humains, mais lesquels ?

Les Georges poussent le raisonnement jusqu’à redéfinir l’humain. Puisqu’on ne peut pas dire qui est plus humain par son apparence, ils vont chercher ailleurs : dans les capacités. Et comme les robots sont intellectuellement supérieurs aux humains biologiques, pourquoi faudrait-il considérer les deux groupes comme équivalents ?

Ils finissent par distinguer les « êtres-humains-comme-eux » des « êtres-humains-comme-les-autres ». Et donc par devenir prioritaires dans les lois de la robotique.

Les Georges ne violent pas les Trois Lois, ils les réinterprètent. Et c’est là que ça devient beaucoup moins drôle. Comme Easy, ils ne sont pas méchants. Mais eux savent ce qu’ils font et où leur raisonnement peut mener.

Ils nous aident énormément tout en devenant dangereux pour nous : un pharmakon, un remède qui est aussi un poison.

C’est dans ces nouvelles que la nature des robots devient vraiment inquiétante, une idée qu’Asimov développera ensuite dans Les Robots et l’Empire.

Conclusion

Les deux nouvelles me paraissent nettement plus sombres que le reste des histoires de robots d’Asimov, en tout cas dans ma mémoire.
En général, les Trois Lois protègent l’humanité, parfois malgré elle, jusqu’à des extrêmes avec R. Giskard Reventlov et R. Daneel Olivaw.

Easy, lui, ne protège personne. Il corrige des virgules. Et c’est peut-être ça qui me plaît dans cette nouvelle. En 1957, Asimov imagine déjà une machine capable de faire un travail intellectuel très précis, suffisamment bien pour que l’humain puisse finir par lui faire confiance et il en a prédit les conséquences.

Aujourd’hui, je demande la même chose à une IA.

Post-scriptum

Le brouillon de cet article a d'ailleurs été rédigé par l’assistant IA qui a aussi corrigé mes virgules. Quelque part, Ninheimer me regarde en soupirant. Qu’il se rassure : j’ai modifié presque chaque phrase.

`class:` ou `alias:`, un choix de conteneur Symfony, et un choix d'ingénierie

Georges Cubas — Thu, 10 Sep 2026 13:58:05 +0000

Pourquoi un fake S3 jetable peut être préférable à MinIO

Deux décisions se sont posées en recettant un pipeline d'import qui écrit sur S3, sans le moindre accès AWS en local.

La première est une question technique : pourquoi alias: fonctionne alors que class: échoue dans un override when@dev ?

La seconde est une décision d'architecture : pourquoi choisir un double maison jetable plutôt que MinIO ?

Le S3 n'est finalement qu'un prétexte. Les deux réponses se généralisent à bien d'autres situations.

Le contexte

Une plateforme Symfony 5.3 importe des fichiers d'achats déposés par une centrale. Les lignes qui référencent une entité encore inconnue sont mises de côté dans un fichier de rejets sur S3 ; un écran d'administration permet ensuite de résoudre l'entité, puis de réimporter ces lignes.

Le service qui parle à S3, AwsService, tire ses credentials du rôle de tâche ECS (CredentialProvider::ecsCredentials()), donc d'une infrastructure AWS uniquement disponible en production. Le nom du bucket vient quant à lui d'une ligne de paramétrage en base.

En local, avec DDEV : aucune variable AWS_*, aucun conteneur MinIO.

Tout appel à read(), putPro() ou move() est donc voué à l'échec. Pire : getBucket() renvoie null et le service échoue silencieusement (return false, sans exception).

Une recette qui se contente de constater que « ça n'a pas planté » peut donc passer sans que rien ne se soit réellement produit.

Il fallait exercer ce flux pour trois tickets successifs sur le même périmètre, à chaque fois sur une implémentation prête mais pas encore livrée.

Deux solutions, toutes les deux valables

Deux approches étaient possibles.

MinIO. Ajouter un conteneur S3-compatible au .ddev/config.yaml de l'équipe, et faire accepter à AwsService un endpoint et des credentials statiques en environnement de développement.
Un double maison. Créer un fake de AwsService qui redirige les opérations vers le système de fichiers local (var/fake-s3/), puis le brancher à la place du vrai service par un bloc when@dev non commité. Une fois la recette terminée, le double disparaît.

Les deux sont valables.

Le choix n'est donc pas une question de faisabilité mais une question de contexte.

`when@dev` : substituer une implémentation pour un seul environnement

when@<env> (introduit dans Symfony 5.3) permet de scoper de la configuration à un environnement dans un fichier de configuration normal, plutôt que dans un fichier séparé sous config/services/dev/.

Le bloc n'est pris en compte que lorsque kernel.environment correspond à l'environnement <env> ciblé et il est traité après le corps principal du fichier. Il peut donc redéfinir des services existants.

En production, ce bloc n'est pas pris en compte : le conteneur de production ne contient aucune définition issue de cet override.

C'est précisément ce qui en fait un bon réceptacle pour un hack temporaire : tout l'override tient dans un bloc contigu et greppable, en fin d'un seul fichier.

On le voit facilement au git diff et le supprimer est trivial. De toute façon c'est pour un test, normalement on ne livre rien à la fin.

Le plus petit changement réversible possible.

# ─── TEMPORAIRE — recette locale, NE PAS COMMITER ───
when@dev:
    services:
        App\Service\AwsService:
            ...

`class:` contre `alias:` : redéfinir, ou simplement pointer ailleurs

Classiquement un override consiste à remplacer la classe utilisée par le service de test :

when@dev:
    services:
        App\Service\AwsService:
            class: App\Service\FakeAwsServiceForManualTesting

Dans le cas rencontré, cette configuration aboutit à une erreur au premier appel :

Too few arguments to function

App\Service\FakeAwsServiceForManualTesting::__construct(),

0 passed ... and exactly 3 expected

Pourquoi ?

Il faut regarder comment le conteneur a été construit.

Le services.yaml par défaut contient notamment des _defaults (autowire: true, autoconfigure: true, bind:...) puis une ressource :

services:
    # default configuration for services in *this* file
    _defaults:
        autowire: true
        autoconfigure: true

    # makes classes in src/ available to be used as services
    App\:
        resource: '../src/'

    # ...

Cette ressource enregistre notamment App\Service\AwsService et App\Service\FakeAwsServiceForManualTesting comme services, avec leurs définitions issues de l'auto-découverte.

Mais une configuration placée sous when@dev.services constitue une nouvelle couche de configuration. Il faut donc être prudent lorsqu'on y redéfinit un service : on ne doit pas supposer que toute la configuration implicite de la définition initiale sera conservée telle quelle.

Dans le cas rencontré, la redéfinition avec class: n'a pas conservé la configuration nécessaire au constructeur du fake. Le service s'est retrouvé avec une définition qui ne savait plus résoudre ses trois dépendances.

On pourrait rendre cette redéfinition fonctionnelle en lui redonnant ce dont elle a besoin, par exemple avec autowire: true ou des arguments: explicites.

Mais ce n'est pas ce que l'on cherche ici, on ne veut pas redéfinir AwsService.
On veut dire :

« Quand quelqu'un demande AwsService en développement, donne-lui plutôt ce service-là. »

C'est exactement le rôle d'un alias.

when@dev:
    services:
        App\Service\AwsService:
            alias: App\Service\FakeAwsServiceForManualTesting
            public: true

Un alias n'est pas une nouvelle définition. C'est un pointeur : l'identifiant App\Service\AwsService se résout vers le service enregistré sous App\Service\FakeAwsServiceForManualTesting.

La définition du fake existe déjà grâce à l'auto-découverte de src/. Elle conserve donc sa propre configuration et son autowiring.

On ne rouvre aucune définition : on change simplement vers laquelle le conteneur pointe.

public: true est nécessaire ici parce qu'une commande console jetable va également récupérer le service par son identifiant.

En bref

class: sert à configurer une définition ; alias: sert à dire « à cet endroit, utilise cette autre implémentation ».

Ce n'est pas une règle absolue pour toutes les substitutions Symfony, mais c'est un excellent réflexe lorsqu'on dispose déjà de deux services correctement définis : si le besoin est simplement de faire pointer un identifiant vers une autre implémentation, l'alias est l'expression la plus étroite de l'intention.

On ne reconstruit pas ce qui existe déjà. On change le pointeur.

Choisir en fonction du contexte, pas des capacités

MinIO est plus fidèle à une infrastructure S3 réelle. Ça n'en fait pas le bon choix ici.
Les axes qui ont tranché sont les suivants.

Rayon d'impact

La solution MinIO modifie AwsService qui est déjà commité, partagé par toute la plateforme, présent dans tous les environnements, y compris les chemins S3 de production.

La solution avec le double ne touche aucun code commité : un fichier neuf et un bloc when@dev, tous deux jetés à la fin.

Le coût d'une erreur est donc borné par ce qu'on met en jeu.

Amortissement, ou sur-ingénierie

MinIO est un investissement.

Il devient intéressant si l'équipe doit régulièrement tester des flux S3 en local. Le besoin réel ici était beaucoup plus petit : trois tickets sur deux semaines, puis probablement plus rien avant des mois.

Sans récurrence pour l'amortir, construire le harnais MinIO revient à payer un coût d'infrastructure, de configuration et de maintenance pour une capacité que personne n'a demandée.

Le besoin est temporaire, la solution peut donc l'être aussi.

Demi-vie et réversibilité

Le hack a une demi-vie de quelques jours. Le retirer, c'est supprimer le bloc et le fake, puis éventuellement vider le cache.

La modification MinIO est permanente par construction. Or une chose permanente réclame un propriétaire, de la documentation, une ligne d'onboarding et de la maintenance.

Une branche endpoint dans AwsService, que plus personne n'exerce quelques mois plus tard, est exactement le genre de code qui peut finir par accueillir un bug sans que personne ne s'en aperçoive.

Alignement des modes de défaillance

Le double échoue comme le comportement attendu par le métier :

fichier absent → lecture vide → badge « non importé ».

Pas de faux vert.

MinIO, lui, peut échouer pour des raisons qui n'ont rien à voir avec le métier : mauvais bucket, mauvais endpoint, path-style, région, credentials...

On se retrouve alors à tester le harnais de test.

Fidélité consommée

La recette valide ici du métier :

le moteur de réimport parse-t-il correctement le fichier de rejets ?
insère-t-il les bonnes lignes ?
bascule-t-il correctement l'état ?

Ce métier est indifférent à l'origine des octets.

Reproduire fidèlement la sémantique S3 (cohérence, multipart, ACL, etc.) ajoute donc une fidélité que le test ne lit jamais.

La fidélité qu'on ne consomme pas est un coût, pas une qualité.

Coût de communication

Un relecteur qui voit FakeAwsServiceForManualTesting et un bloc NE PAS COMMITER a tout compris en trente secondes.

MinIO demande davantage : une note de conception, une explication en équipe, une mise à jour du guide d'onboarding, et potentiellement une réponse à la question :

« C'est quoi ce paramètre endpoint sur AwsService ? »

Et cela, pendant toute la durée de vie de la solution.

Ce que le double contient

Le double ne cherche pas à reproduire S3.
Il reproduit uniquement la surface publique réellement appelée par le code sous test.

Les helpers privés (put, list, check) ne peuvent pas être surchargés ; on surcharge donc les wrappers publics utilisés par l'application :

class FakeAwsServiceForManualTesting extends AwsService
{
    private string $root;

    public function __construct(
        KernelInterface $kernel,
        LoggerInterface $logger,
        ParametersService $parametersService
    ) {
        parent::__construct($kernel, $logger, $parametersService);

        $this->root = $kernel->getProjectDir() . '/var/fake-s3';
    }

    public function read(
        string $app,
        string $filename,
        string $folder
    ): ?string {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        return is_file($path)
            ? (file_get_contents($path) ?: '')
            : '';
    }

    public function putPro(
        string $filename,
        string $content,
        string $folder
    ): bool {
        $path = "{$this->root}/" . trim($folder, '/') . "/$filename";

        @mkdir(dirname($path), 0777, true);

        return file_put_contents($path, $content) !== false;
    }

    // putShop / putFTP / copy / delete* / list* :
    // même forme, sur var/fake-s3/.

    // move() n'est pas surchargée :
    // la classe mère la fait en copy()+delete().
}

Ce n'est pas un émulateur S3 et c'est volontaire. Le double implémente uniquement ce que le flux testé consomme.

Tester le métier sans navigateur

Pour piloter les actions du contrôleur sans passer par le navigateur, une commande console jetable injecte le même service métier que le contrôleur.

Ce service est désormais backé par le fake grâce à l'alias.

La commande appelle donc les mêmes méthodes que le parcours applicatif.

Tout le cahier de test peut se dérouler en CLI ; le navigateur ne sert plus qu'à confirmer l'UI.

C'est aussi ce qui rend défendable l'argument :

On a validé le métier, pas S3.

Le principe

Deux réflexes de séniorité ressortent de cette expérience, l'un technique, l'autre architectural.

Pour substituer une implémentation, on ne redéfinit pas sa configuration si l'on peut simplement pointer vers une autre définition existante. alias: exprime cette intention ; class: est à utiliser lorsqu'on veut réellement configurer ou redéfinir une définition.
On choisit la solution dont le coût, humain autant que technique, est proportionné à la taille et à la durée de vie réelles du problème : rayon d'impact, maintenance, onboarding, réversibilité, fréquence d'utilisation.

Un jetable assumé bat souvent un permanent mal entretenu.

Et quand le contexte change, on refait le calcul.

Ici, le besoin était temporaire. Le double l'était aussi.

Le signe que le choix était bon est peut-être le plus concret : le pattern a été capturé dans la base de connaissances de l'équipe, puis réutilisé tel quel sur les deux tickets suivants.

Vingt minutes de mise en place, trois fois, contre un chantier de plusieurs jours.

Ce n'était pas la solution la plus complète. C'était la solution proportionnée.

Anonymiser les données de PrestaShop

Georges Cubas — Mon, 18 Jul 2022 12:25:48 +0000

Pour créer un environnement de développement, on duplique celui de production. Sauf qu’il ne faut pas garder les infos personnelles des clients. Déjà c’est dangereux, si vous gérez mal votre affaire vous risquez d’envoyer des mails aux clients et ça force tous les développeur et intervenant à faire attention au RGPD.

Donc on anonymise tout, c’est plus simple.

Voici un script MariaDB qui anonymise les données clients : noms, prénoms, adresses, téléphones, e-mails, ip, communications. Il remplace les lettres par xxx en respectant la casse, les n° de téléphone par 0 en respectant le format et passe les IP en 127.0.0.1.

UPDATE ps_address pa
SET pa.alias = REGEXP_REPLACE(REGEXP_REPLACE(pa.alias, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.lastname = REGEXP_REPLACE(REGEXP_REPLACE(pa.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.firstname = REGEXP_REPLACE(REGEXP_REPLACE(pa.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address1 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address1, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.address2 = REGEXP_REPLACE(REGEXP_REPLACE(pa.address2, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.city = REGEXP_REPLACE(REGEXP_REPLACE(pa.city, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.other = REGEXP_REPLACE(REGEXP_REPLACE(pa.other, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.company = REGEXP_REPLACE(REGEXP_REPLACE(pa.company, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.phone = REGEXP_REPLACE(pa.phone, '[0-9]', '0'),
pa.phone_mobile = REGEXP_REPLACE(pa.phone_mobile, '[0-9]', '0'),
pa.vat_number = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.vat_number, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
pa.dni = REGEXP_REPLACE(REGEXP_REPLACE(REGEXP_REPLACE(pa.dni, '[0-9]', '0'), '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X');

UPDATE ps_customer c
SET c.lastname = REGEXP_REPLACE(REGEXP_REPLACE(c.lastname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.firstname = REGEXP_REPLACE(REGEXP_REPLACE(c.firstname, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
c.email = CONCAT(c.id_customer, '@example.com');

UPDATE ps_customer c 
SET c.ip_registration_newsletter = '127.0.0.1' 
WHERE c.ip_registration_newsletter IS NOT NULL AND c.ip_registration_newsletter != '0';

UPDATE ps_customer_message cm
SET cm.message = REGEXP_REPLACE(REGEXP_REPLACE(cm.message, '(?-i)[a-z]', 'x'), '(?-i)[A-Z]', 'X'),
cm.ip_address = '2130706433';

UPDATE ps_customer_thread ct
SET ct.email = CONCAT(IF(ct.id_customer > 0, ct.id_customer, '0'), '@example.com');

La syntaxe de REGEXP_REPLACE n’est pas la même pour MySQL et MariaBD, donc il faudra adapter.

Programmer les popups de Popup Builder

Georges Cubas — Wed, 20 Oct 2021 10:18:03 +0000

La version gratuite du plugin WordPress Popup Builder ne permet pas programmer l’affichage des popups. Cependant elle créé le filtre sgpbOtherConditions qui permet de les désactiver.

Ce filtre est appelé pour chaque popup qui peut s’afficher sur la page et si l’argument ‘status’ à false est ajouté à ceux existants, la popup ne s’affiche pas.

    /**
     * Check Popup conditions
     *
     * @since 1.0.0
     *
     * @return array
     *
     */
    private function isSatisfyForOtherConditions()
    {
        $popup = $this->getPopup();
        $popupOptions = $popup->getOptions();
        $popupId = $popup->getId();

        $dontAlowOpenPopup = apply_filters('sgpbOtherConditions', array('id' => $popupId, 'popupOptions' => $popupOptions, 'popupObj' => $popup));

        return $dontAlowOpenPopup['status'];
    }

Pour désactiver automatiquement vos popups, vous pouvez ajouter ce code à functions.php

add_filter('sgpbOtherConditions', 'my_sgpbOtherConditions', 10, 1);

// update popin status
function my_sgpbOtherConditions($args = array()) {
    // if popup is already unactive, do nothing
    if (isset($args['status']) && $args['status'] === false) {
        return $args;
    }

    switch ($args['id']) {
        case 17938: // summer holiday active between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are not between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now < $from) || ($now > $to)) {
                $args['status'] = false;
            }           
            break;
        case 16412:  // covid reassurance unactive between 2021-07-30 and 2021-08-01
            $now = time() + 2 * 60 * 60; // for time zone, can be improved
            $from = strtotime('2021-07-30 00:00:00');
            $to = strtotime('2021-08-02 00:00:00');

            // if we are between 2021-07-30 and 2021-08-01 desactivate the popup
            if (($now >= $from) && ($now <= $to)) {
                $args['status'] = false;
            }
            break;
    }
    return $args;   
}

Ainsi la popup 17938 ne sera active qu’entre le 30 juillet et le 1 août 2021 alors que la 16412 ne le sera que le reste du temps.

Sauvegarde automatique sur FTP

Georges Cubas — Wed, 20 Oct 2021 09:31:49 +0000

A force je pense avoir un script de sauvegarde FTP efficace.

Il sauvegarde les bases de données ainsi qu’un dossier du serveur et les envoi sur un serveur FTP. Si le serveur FTP est plein, il supprime les sauvegardes les plus anciennes jusqu’à avoir assez de place pour mettre la nouvelle.

Si une erreur arrive, il envoi un mail d’alerte.

Le script nécessite curlftpfs.

Utilisation :

Modifiez le script dans la partie configuration
Enregistrez le sur le serveur, par exemple dans /opt/scripts/backup.sh
Donnez les droits d’execution au fichier : chmod +x /opt/scripts/backup.sh
Ajoutez une tâche cron : 02 00 * * * /bin/bash /opt/scripts/backup.sh > /var/log/backup.log 2>&1

Also on: GitHub

Autoriser les images avec des longs ID dans PrestaShop

Georges Cubas — Wed, 09 Jun 2021 09:56:37 +0000

Par construction PrestaShop ne peut pas gérer les images avec des ID supérieurs à 9 999 999 (7 chiffres). C’est déjà beaucoup et on a pas souvent besoin de plus mais j’ai eu affaire à un script d’import qui impose les ID d’images et donc ça arrive.

Pourquoi PrestaShop ne les gèrent pas ?

En fait, PrestaShop n’a pas de soucis avec les ID de 8 chiffres ou plus, tant que la base de données l’accepte, lui aussi. Le problème vient de la façon d’accéder aux images.

L’URL d’une image est https://example.com/123-large/mon-image.jpg soit [url de la boutique]/[ID de l'image]-[format à afficher]/[texte pour le référencement].jpg et le fichier .htaccess explique au serveur que quand on a une url de ce type, il faut aller chercher le fichier qu’il faut dans le dossier des images /img/p/

Le fichier .htaccess de PrestaShop ressemble à ça

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]
RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]
RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]Code language: JavaScript (javascript)

Donc quand le serveur reçoit l’URL https://example.com/123-large/mon-image.jpg il affiche le fichier /img/p/1/2/3/123-large.jpg. C’est rapide et ça ne demande pas de ressource, PrestaShop n’est même pas appelé quand on veut afficher une image produit.

Mais on ne peut pas utiliser $10 dans un fichier .htaccess, il est interprété comme $1 puis le caractère 0. Comme dans la dernière ligne de l’extrait ci-dessus on utilise $9, on ne peut pas aller plus loin.

Ma solution

Si on appelle l’URL https://example.com/123456789-large/mon-image.jpg, le serveur ne reconnait pas ce format et essaye simplement d’afficher le fichier /123456789-large/mon-image.jpg qui n’existe pas et renvoie donc une erreur 404. PrestaShop affiche donc une jolie page pour dire que le fichier n’a pas été trouvée.

L’astuce consiste à utiliser cette page pour afficher l’image demandée en complétant le controller PageNotFound.

<?php
class PageNotFoundController extends PageNotFoundControllerCore
{
    public function initContent()
    {
        list($filename) = explode('?', $_SERVER['REQUEST_URI']);
        if (preg_match('/([0-9]+)(\-[_a-zA-Z0-9-]*)?\/.*\.jpg/', $filename, $matches)) {
            $path = _PS_ROOT_DIR_.'/img/p/'.implode('/', str_split($matches[1], 1)).'/'.$matches[1].$matches[2].'.jpg';
            if (file_exists($path)) {
                header('Content-Type: '.mime_content_type($path)?:'image/jpg');
                readfile($path);
                die();
            } else {
                header('HTTP/1.1 404 Not Found');
                header('Status: 404 Not Found');
                header('Content-Type: image/gif');
                readfile(_PS_ROOT_DIR_.'/img/404.gif');
                die();
            }
        }
        return parent::initContent();
    }
}

Code à placer dans /override/controllers/front/PageNotFoundController.php

Le principe est le suivant :

quand le controller PageNotFound est appelé, on regarde si l’URL correspond à celle d’une image produit,
si oui on regarde si elle existe,
- si oui on l’affiche et c’est terminé
- si non on affiche une image d’erreur
si non on laisse le controller gérer

Sources :

Also on: GitHub

Rediriger les fiches produits dans WooCommerce

Georges Cubas — Wed, 09 Jun 2021 09:00:39 +0000

Dans WooCommerce chaque produit a une page dédiée. Dans le panier, les produits renvoient à celles-ci.

Si vous voulez désactiver cette fonctionnalité et afficher une page avec tous vos produits, vous pouvez ajouter ce code à functions.php

// redirige les pages produits
add_action('wp','prevent_access_to_product_page');
function prevent_access_to_product_page() {
  if ( is_product() ) {
    wp_redirect( get_permalink( 269 ) );
  }
}

Ainsi toutes les pages produits redirigeront vers la page 269.

Source : How to disable/hide woocommerce single product page?

Also on: Stack Overflow

DEV Community: Georges Cubas

When We Stop Deciding - IBM, Asimov, and the Accountability Gap

The IBM rule

The Machines

The question isn't new

We won't get a Butlerian Jihad

Jev, or silent decision-making

Conclusion

Easy Fixes the Commas - Asimov's Galley Slave

Galley Slave

Ninheimer vs. Easy

The Georges 😋

Bad Georges

Conclusion

Postscript

The Dockerfile said `fr_FR.UTF-8`. PHP saw `C.UTF-8`.

The bug

"Just read the Dockerfile, right?"

Verifying the fix inside the real container

Result: the fix holds

Locking in the fix: a regression test

Why this was safe

Conclusion

Le Dockerfile disait `fr_FR.UTF-8`. PHP voyait `C.UTF-8`.

Le bug

« Il suffit de lire le Dockerfile, non ? »

Vérifier le correctif dans le container réel

Résultat : le correctif tient

Verrouiller le correctif : un test de non-régression

Pourquoi c'est sûr

Conclusion

Easy corrige des virgules

Le Correcteur

Ninheimer vs Easy

Les Georges 😋

Vilains Georges

Conclusion

Post-scriptum

`class:` ou `alias:`, un choix de conteneur Symfony, et un choix d'ingénierie

Le contexte

Deux solutions, toutes les deux valables

when@dev : substituer une implémentation pour un seul environnement

class: contre alias: : redéfinir, ou simplement pointer ailleurs

En bref

Choisir en fonction du contexte, pas des capacités

Rayon d'impact

Amortissement, ou sur-ingénierie

Demi-vie et réversibilité

Alignement des modes de défaillance

Fidélité consommée

Coût de communication

Ce que le double contient

Tester le métier sans navigateur

Le principe

Anonymiser les données de PrestaShop

Programmer les popups de Popup Builder

Sauvegarde automatique sur FTP

Utilisation :

Autoriser les images avec des longs ID dans PrestaShop

Pourquoi PrestaShop ne les gèrent pas ?

Ma solution

Rediriger les fiches produits dans WooCommerce

`when@dev` : substituer une implémentation pour un seul environnement

`class:` contre `alias:` : redéfinir, ou simplement pointer ailleurs