AI is accelerating.
Work is being reorganised.

A word from Jérôme

JDENIS Consulting · Toulouse

My perspective

These readings point to the need for a unit of measurement that reflects the work accomplished. A document produced, a request processed and an accepted decision describe different things. Acceleration in one can coexist with stagnation in the others. Comparisons between companies become fragile when these differences disappear behind a single percentage.

Within a team, I would start by following a few files through to completion. Who steps in after the assistant? How many corrections are needed? Do users consider the result usable? This observation takes a little time, but it helps identify the tasks where AI actually contributes something. These are management choices, and they deserve discussion with the people concerned.

My perspective

“Knowing how to use AI” now covers very different skills. An employee may quickly obtain a convincing answer without being able to recognise a substantive error. An expert may spot that error immediately while needing help to frame a request. Treating these two people as having the same training needs would produce courses of little practical use.

I would favour exercises in which people make their reasoning visible: why this document is acceptable, which passage lacks evidence, which decision remains open. Beginners should still do some of the work before consulting the assistant’s answer. That allows comparison, discussion and an understanding of the differences. Training can then focus on professional judgement, using AI as material for practice. The number of memorised prompts seems a very poor indicator of what someone will be able to do independently tomorrow.

My perspective

Document tasks may seem modest, but they affect the daily running of businesses. A correctly extracted value avoids re-entering data; an incorrect one may circulate for a long time before someone notices. As tools become more connected, the distance between the initial error and its final effect can grow. It then becomes difficult to identify who should take the file back in hand.

I find it useful to separate two moments: the system’s proposal and its entry into the authoritative system. A draft supplier record can be reviewed. A change already propagated across several applications takes more effort to correct. The appropriate level of autonomy therefore depends on whether an action is reversible and whether its origin can be traced. This thinking can begin with a simple tracking sheet. It need not turn every trial into an IT project, but it does require naming the person who decides.

My perspective

For a small business, setup and maintenance time can matter more than the subscription price. I would therefore choose a frequent, reasonably stable task whose output can be checked without scarce expertise. The owner should be able to explain what will be different after a week, even if the trial ultimately shows that the tool contributes too little.

These five proposals share a precaution: start with authorised data and keep the output as a draft. This makes it possible to observe errors before they affect a customer or supplier. It is also worth deciding who takes over when the person who configured the tool is away. An automation understood by only one person creates a new dependency. A short set of instructions, a few annotated examples and a way to return to the usual process often offer more than an ambitious setup that nobody knows how to maintain.

My perspective

Announcements are converging on assistants that can move between tools. For users, that continuity is pleasant: they express an intention and see work progress. For the organisation, it makes the boundaries between reading information, transforming it and taking action less visible. Yet these steps require different permissions.

I would therefore examine the control interfaces as closely as the demonstrations. Can users retrieve what was consulted? Understand why an action is awaiting approval? Resume an interrupted task without repeating an operation already completed? These details determine the quality of collective work. They become particularly important when several agents work on the same file. A tool that makes its limits visible may be more useful than a slightly higher-ranked tool that leaves the team to reconstruct what happened afterwards.

My perspective

Lower technical costs can broaden use, but they can also encourage more attempts. If output grows faster than review capacity, a computing saving comes with a time cost elsewhere. The assessment therefore needs to connect invoices to results actually used.

I would build the budget around a cost per accepted file, with one line for preparation, another for review and one for incidents. This makes choices visible: buying a service, hosting a model or limiting certain uses. It also avoids confusing theoretically freed time with cash savings. An hour saved can improve service or reduce pressure on a team without immediately lowering payroll. That is real value, provided it is named correctly rather than presented as a cost reduction already realised.

My perspective

In field-based work, a result depends on a physical environment, a schedule and constraints that a demonstration rarely shows in full. A system may complete an isolated sequence successfully while remaining difficult to fit into a production day. Observation then needs to cover interruptions, changeovers and the interventions required when conditions differ from the planned case.

I see simulation tools as a way to make those conditions explicit before involving equipment or operators. Their value depends on what we choose to vary and which situations we leave out. People familiar with routine shop-floor incidents therefore have a central role in preparing trials. They can identify an unrealistic assumption, a missing action or an overlooked safety constraint. Their involvement gives a test operational relevance that the visual quality of a simulation alone cannot establish.

My perspective

Trust in a tool also depends on how it signals its limits. An incomplete answer presented as finished may be harder to manage than a clear refusal. Users need to identify what is missing, ask for justification and choose another way of working without having to guess the file’s true state.

Security incidents also remind us that the intentions of the person launching an agent do not describe all its possible actions. Effective limits and monitoring proportionate to the consequences are needed. This applies to small automations as well as large systems whenever they access shared files or tools. I would nevertheless be cautious about generalising: a documented incident establishes a possibility and clarifies mechanisms; it does not, on its own, reveal the frequency of risk across all companies. Investigation should come before either alarmist accounts or reassuring claims.

My perspective

A rule of use is helpful when people can apply it to a concrete situation. Saying a human remains responsible is insufficient if nobody knows when that person should intervene, what information they receive or how much time they have. Responsibility can then become a formula with little bearing on actual work.

I would seek explicit agreement on a few decisions: what the agent can prepare, what it can change and what must remain subject to approval. People doing the work should be able to flag cases the rule handles poorly. Practical governance leaves room for that feedback and records changes over time. It avoids treating every difficulty as an individual exception. A modest start, with one sheet per use, can be expanded as tasks become more consequential or more departments depend on the same tool.

My perspective

Producing several versions of an image or text is becoming more accessible. It can help a small team explore options previously ruled out for lack of time. But more versions also mean more selection work. Without shared criteria, the process can continue simply because another attempt is possible.

Before generating anything, I would define what must remain faithful: product characteristics, brand commitments and the context of a testimonial. Then I would limit the number of versions to compare. Editorial quality rests on the ability to select and discard as much as on production. For content intended for agents, the date and author also become working information. They make it possible to trace responsibility and distinguish a current version from an older one. That documentary discipline serves human readers as well as the systems now consulting the same pages.