AI Maturity of French SMEs 2025-2026

Preamble: moving from use to capability

AI adoption is rising quickly among small businesses, but a usage rate reveals neither whether processes have changed, nor whether value is measured, nor whether risks are controlled: maturity describes an organisational capability, not the presence of a tool.

• The 2025 France Num Barometer finds that 26% of French microbusinesses and SMEs use at least one AI solution, from a survey of 11,021 businesses [1].
• The public “Osez l’IA” plan aims for 80% of SMEs and mid-caps to use AI by 2030; this target does not map to any Junyr level [2].
• KPMG identifies 11% of respondents as “AI leaders” in a global sample of organisations with at least US$100 million in annual revenue, three quarters of which exceed US$1 billion; the result illustrates the gap between experimentation and scale without estimating the maturity of French SMEs [3].
• This white paper turns those observations into decisions: diagnose, choose a use case, prepare data and governance, then measure before expanding.

The working thesis is that lasting advantage comes from the ability to choose, integrate, control and improve AI in operations, because models and prices change faster than processes, responsibilities and evidence of value.

• Choose: connect each use case to a business problem, an owner and a measure.
• Integrate: address data, rights, interfaces and changing roles before automation.
• Control: reserve defined decisions for people, log actions and prepare a stop procedure.
• Improve: compare results with the baseline and revise the system at every cycle.

Chapter 1: reading the state of play correctly

Available surveys measure different populations and objects; they become useful to an SME when adoption, depth of use, value creation and governance remain separate instead of being compressed into a single percentage.

• Adoption: France Num asks whether a business uses an AI solution; content generation and assistants remain the dominant uses [1].
• Depth: task automation and data analysis are much less common than surface-level generative AI in the same survey [1].
• Value: KPMG reports that 64% of its large-organisation sample sees meaningful business outcomes, while its 11% AI-leader cohort is defined by maturity and agent deployment [3].
• Governance: policies, accountable owners, controls and measures must be observed directly; an adoption rate cannot establish their presence.

Differences between surveys are therefore not automatic contradictions: France Num covers French microbusinesses and SMEs, KPMG covers large global organisations, and vendor or consultancy studies often describe leaders, functions or projects rather than a comparable national population.

• Retain the exact definition of an indicator before repeating its percentage.
• State sample size, geography and date when a finding informs a decision.
• Present associations as associations rather than causation or a success probability for an individual client.
• Use engagement observations to improve the method until their protocol and base are published.

The cost of waiting is not a prediction that late adopters will disappear; it becomes concrete when uncontrolled uses spread, data remain unusable or a competitor learns faster on a decisive process.

• Map existing uses, including personal accounts and AI features embedded in software.
• Identify a process where time, quality or workload can actually be measured.
• Decide what must be learnt now and what can wait for more stable technology.
• Protect exit options through exportable data, reversible contracts and documented integrations.

The AI Act: reason by role, system and use

The EU regulation does not impose one uniform obligation on every form of “enterprise AI”: the work starts by identifying the organisation’s role, the system and its use, then applying the relevant duties and dates with legal advice where the stakes warrant it [4][5].

• An organisation may be a provider, deployer, importer or distributor depending on what it develops, markets and operates.
• Risk classification depends on use; the same model may support an ordinary case or a high-risk system.
• Regulation (EU) 2026/1744 amended Article 4: providers and deployers support the development of AI literacy without guaranteeing a particular level for every individual [5].
• The relevant sections for Annex III high-risk systems apply from 2 December 2027; those for Annex I systems apply from 2 August 2028, subject to the regulation’s transitional rules [5].
• Reaching a Junyr level supports inventory, accountability and evidence, but never guarantees compliance.

Chapter 2: the Junyr Method™ Scale

The Junyr Scale is a proprietary five-level decision framework describing an organisation’s ability to turn individual use into a measured and governed system, with cumulative evidence adapted to the SME’s context.

The levels are cumulative: sophisticated architecture does not compensate for the absence of a business owner, and many users do not compensate for missing controls, measures or an incident procedure.

• Buying a tool does not raise the level; demonstrating a repeatable capability does.
• One use case may be advanced while the organisation as a whole remains at Artisan level.
• Maturity should be documented by dimension and reassessed after a major change of process, supplier or regulation.
• Budgets and timescales are estimated from the business’s scope, data debt, integrations and risk requirements.

The nine dimensions to examine

The Junyr framework examines nine distinct dimensions that together describe the move from individual use to durable capability; each axis progresses qualitatively and rests on observable evidence suited to the business.

• Sovereignty and control of models: service origin, data location and use, control of keys, contractual terms and the ability to change models.
• Resilience and continuity: critical dependencies, backups, degraded modes, recovery, portability and exit tests for outages or supplier disruption.
• Augmented staff: eligible roles, approved tools, quality of use, accessible assistance and clear continuing human accountability.
• AI literacy and culture: role-appropriate knowledge, understanding of limitations, continuous learning and the ability to verify or challenge an output.
• AI governance: sponsor, owners, policies, register, employee representation, choices and supervision proportionate to risk.
• Technical debt: scripts, integrations, dependencies, documentation, tests and backlog needed to keep the system maintainable.
• Security: classification, identities, secrets, logging, threat assessment, incidents and supply chain.
• Workflows and agents: process-integrated uses, authorised tools, autonomy limits, human approvals, evaluation and fallback.
• Value and FinOps: baseline, adoption, quality, TCO, attributable benefits, cost per outcome and sensitivity of assumptions.

Progression is read axis by axis: the overall level is the highest stage whose essential capabilities are established across the chosen perimeter.

A twelve-question self-assessment

This questionnaire prepares an assessment interview: answers are evidence to gather and higher levels require all their prerequisites, preventing a strong total score from hiding a critical gap.

• Q1. Are the tools actually used, including personal accounts, inventoried?
• Q2. Do staff know which data and uses are prohibited, permitted or subject to approval?
• Q3. Does every priority use case have a sponsor, business owner and measure?
• Q4. Is there a baseline for time, quality, cost or risk before the pilot?
• Q5. Does at least one recurring use operate in production with a fallback procedure?
• Q6. Are adoption, quality, incidents, costs and impact reviewed together each month?
• Q7. Does the register identify the company’s role, the use, data, supplier and risk?
• Q8. Are identities, permissions, secrets, logs and integrations controlled and tested?
• Q9. Are TCO and ROI calculated for an explicit period and perimeter?
• Q10. Do model changes, incidents and supplier exits have an owned procedure?
• Q11. Have several processes been redesigned with limits on autonomy and proportionate supervision?
• Q12. Are outcomes, risks and controls reviewed by a function independent of the project where risk requires it?

Interpretation uses gates rather than an interchangeable sum of “yes” answers: assign the highest level for which all essential evidence is present.

• Spectateur: Q1 or Q2 is missing; visibility and a usage rule come first.
• Artisan: Q1-Q2 are established, but one or more of Q3-Q6 are missing.
• Orchestre: Q1-Q6 are established; uses are coordinated and monitored.
• Architecte: Q1-Q10 are established; the platform and governance are operable.
• Pionnier: Q1-Q12 are established across several processes, with durable outcomes and risk-appropriate independent review.

Chapter 3: five mistakes that block scaling

Deployment failures often stem from a sequence of avoidable decisions rather than an intrinsic weakness in the model; these five mistakes cover problem selection, production, change management, economics and data.

• The gadget: starting with a tool and looking for a problem afterwards; remedy, start with a measured pain point and an owner.
• The perpetual PoC: testing without production-entry criteria or a decision date; remedy, set thresholds for quality, cost, adoption and risk before the pilot.
• The lone leader: giving AI to one person without time, authority or business relays; remedy, allocate sponsor, owner, technical, risk and user-representative roles.
• The instant-ROI mirage: announcing a gain before a baseline or confusing released capacity with cash savings; remedy, measure over an explicit period and include full costs.
• Data blindness: automating a process whose sources, rights and exceptions are uncontrolled; remedy, prepare a small reliable corpus before integration.

The rule that no level is skipped is a sequencing rule, not a failure statistic: foundations from the previous level must be evidenced before adding autonomy, integrations or organisation-wide reach.

• A pilot may explore advanced technology early in an isolated environment.
• Production requires controls, data, owners and measures proportionate to the risk.
• Investment grows only after evidence at the previous stage is sufficient.
• The decision rests on pilot criteria and the quality of the foundations, without applying a generic failure rate to an individual business.

Chapter 4: sovereignty and infrastructure

The choice among a global API, European cloud, qualified environment and local deployment should follow data sensitivity, obligations, latency, continuity, volume and available skills; no option is sovereign or profitable by name alone.

• Data: where are they processed, logged, backed up and legally accessible?
• Control: who manages keys, identities, updates, models and subcontractors?
• Resilience: what degraded mode remains acceptable during a network outage, model withdrawal or supplier incident?
• Portability: can data, evaluations, prompts, logs and configurations be exported in a usable form?
• Skills: can the business operate, secure and update a local stack without creating a greater risk?

Comparing cloud and on-premise economics

Local-deployment economics require a complete measured scenario, because token volume alone cannot absorb hardware, energy, operations, redundancy, security and renewal.

• Cloud: input and output usage, storage, network, tools, support, peaks and contractual discounts.
• Local: hardware purchase or rental, energy, hosting, availability, staff, updates, security, insurance and residual value.
• Comparability: the same model or service level, quality, latency, availability and workload growth.
• Decision: select local deployment if its risk-adjusted TCO is better or if a control requirement justifies the premium.
• Caution: at low inference prices, modest use will rarely fund local infrastructure through token savings alone; the decision therefore requires the full calculation above.

The practical matrix separates four data families and adjusts the environment to their risk, while allowing a specific assessment to override the general category.

Jurisdiction, contracts and data access

A server’s location does not fully describe a service’s legal exposure: the CLOUD Act can require a provider subject to US jurisdiction to produce data it controls, including data stored abroad, through valid legal process [9].

• Examine contracting entities, subcontractors and the countries from which access is possible.
• Clarify how the provider handles authority requests and whether notification or challenge is available.
• Document the technical and contractual measures appropriate to the data with the legal owner.

When selecting a supplier, an SME can request a short evidence pack that converts commercial sovereignty claims into verifiable commitments about operations, data and the ability to leave.

• Data: processing and backup locations, input and output retention, any training use and effective deletion.
• Operations: expected availability, support, administrator access, incident handling and responsibility for updates.
• Control: identities, keys, exportable logs, restrictions on agents’ tools and evidence of testing.
• Exit: export formats, timescale, residual costs and a recovery test on an alternative service.

Open-weight models, retrieval and quantisation

An open-weight model provides more hosting and operating choices, but selection should remain grounded in the SME’s tasks, the licence, total cost and the skills needed to maintain a reliable service.

• Test candidate models on the same business corpus, covering routine, rare and deliberately difficult cases.
• Use source-linked retrieval when answers depend on current internal knowledge, and measure retrieval failures as well as answer quality.
• Consider model adaptation only where evaluation identifies a need that instructions, tools or the corpus do not adequately address.
• Check the rights attached to weights, code and data separately: public availability does not remove licence conditions.

Quantisation reduces the numerical precision of some calculations or parameters to lower memory requirements, with trade-offs depending on the method, hardware and expected quality; it enables some configurations without establishing their business suitability [10].

• Memory: size the weights, context, cache and number of concurrent requests.
• Performance: measure throughput and latency on the hardware and inference engine actually used.
• Quality: compare errors before and after quantisation on the business evaluation set.
• Operations: plan updates, security controls and fallback capacity.

Preparing the cryptographic transition

Post-quantum preparation follows the required confidentiality lifetime and the time needed to replace cryptographic components; ANSSI’s 2027 marker concerns entry into product qualification, while a migration schedule does not predict a certain date when existing cryptography will break [8].

• Inventory exchanges, signatures, certificates and cryptographic dependencies.
• Prioritise secrets requiring long-term protection.
• Request suppliers’ update plans and available evidence.
• Test relevant hybrid solutions against ANSSI guidance and interoperability constraints.

Relating obligations to the actual scope

NIS2 and the Data Act address different questions for an SME: the former sets cybersecurity requirements for entities within its scope, while the latter governs matters including switching between data-processing providers [11][12].

• NIS2 scope: assess sector, size, exceptions and applicable national implementation before concluding that an entity is covered.
• Supply chain: distinguish a direct legal duty from security requirements requested by a customer in its contract.
• Cloud switching: examine export and transition terms; the Data Act removes switching charges, including data-egress charges, from 12 January 2027.
• Operational evidence: test export and recovery, because a contractual right alone does not demonstrate application portability.

Chapter 5: FinOps, TCO and return on investment

Model unit costs often fall while the total bill rises with volume, agentic chains and integrations; management should therefore focus on cost per reliable business outcome rather than the price of one million tokens alone.

• Measure volume by team, use case, model and environment.
• Route each task to the least expensive model that reaches the required quality threshold.
• Cache only stable content, with clear invalidation and confidentiality policies.
• Set caps, alerts, quotas and exception procedures in a gateway or control layer that can actually enforce them.
• Review cost, quality, latency, adoption and impact together each month.

TCO includes every cost needed to obtain and maintain the result over the period, including items often left outside the software budget.

• Licences, model calls, storage, network and observability tools.
• Integration, data cleaning, evaluations, security and compliance.
• Training, change management, support and business-expert time.
• Operations, incidents, supplier dependency, reversibility and hardware renewal.

ROI for a period is (attributable benefits − total costs) / total costs, with benefits converted according to their nature and without counting the same released hour twice.

• Cash savings: expenditure actually avoided, net of displacement effects.
• Released capacity: available hours valued separately until they reduce expenditure or generate demonstrable margin.
• Growth: attributable incremental margin, not gross revenue or pipeline.
• Risk: documented change in expected loss, with probability and impact stated.
• Sensitivity: low, central and high cases for adoption, quality, volume and costs.

A control layer that enforces decisions

Budget control requires a layer that can approve or refuse calls before expenditure is committed, then reconcile the estimate with the amount actually charged; an observability dashboard provides useful information without necessarily performing that enforcement function.

• Admission: authenticate the caller, check the project and reserve an estimated budget before sending the request.
• Execution: limit steps, duration, retries and the tools available to the process.
• Reconciliation: replace the estimate with observed cost and handle discrepancies, including concurrent calls.
• Exception: provide an approved increase or a degraded service when the cap is reached.

A monthly review becomes useful when every deviation leads to an assigned action, because a lower unit price can conceal unnecessary volume, poorer quality or a more expensive operational dependency.

• Volume: separate expected growth from duplicates, loops and unused requests.
• Quality: track rework and refusals using a stable comparison between versions.
• Economics: review full cost per accepted result and the actual use of released capacity.
• Decision: name the person who will keep, adjust, expand or stop the use, with a deadline and expected measure.

Worked example: released capacity and ROI

This entirely illustrative example shows why time savings alone cannot establish a financial ROI: the same pilot can release substantial capacity while producing a negative economic result in its first year.

• Scope: 2,000 cases processed during the year, with twenty net minutes saved per case, including review and correction.
• Capacity: 666.7 hours released, valued at approximately €26,667 using €40 per hour; this amount remains separate from the financial benefits below.
• Realised benefits: €18,000 of external services avoided and €10,000 of attributable incremental margin, with no overlap between those two items.
• Full costs: €30,000 over the same year, covering implementation, operations and support.

The decision then depends on the assumptions that can change the result, keeping the period consistent and avoiding double-counting an hour already contributing to an avoided service cost or incremental margin.

• Test lower adoption and more frequent rework.
• Separate start-up and recurring costs before projecting the following year.
• Compare an extension’s cost with its marginal benefit instead of mechanically extending the average ROI.
• Agree the threshold and review date with the business owner and finance.

Using ISO/IEC 42001 appropriately

ISO/IEC 42001 provides an AI management framework for organising responsibilities, risks and continual improvement; its usefulness depends on the scope covered and the practices actually implemented in the business [7].

• Define the activities and systems covered before building the documentation.
• Connect policies with decisions, controls and evidence of operation.
• Consider certification according to commercial and governance needs.
• Assess applicable legal obligations and each system’s performance separately.

Chapter 6: a five-phase method

Transformation advances through successive evidence: each phase reduces a specific uncertainty and ends with a decision to continue, redesign or stop before committing more data, integrations and human change.

• 1. Diagnose: inventory uses, processes, data, risks, skills and costs; output, level by dimension and priority gaps.
• 2. Frame: select a small portfolio by value, feasibility and risk; output, owner, baseline, thresholds and evaluation protocol.
• 3. Prepare foundations: ready the corpus, rights, architecture, security, training and fallback; output, an environment ready to test.
• 4. Pilot: test with real users and representative cases; output, a documented decision based on quality, adoption, cost, time and incidents.
• 5. Consolidate: industrialise, log, version, review and extend; output, an operations review and updated portfolio.

Directing AI through context

System quality depends more on context, tools, examples, limits and evaluation than on an isolated prompt formula; “directing AI” therefore means designing a controlled execution environment.

• Define the objective, expected format and success criteria.
• Provide only the authorised, current and necessary sources.
• Constrain available tools, prohibited actions and human approvals.
• Test normal, boundary and adversarial cases before every material change.
• Retain version, sources, outcome, approval and incident to support learning.

Chapter 7: INDUSTEC, an evaluation protocol for quotation assistance

The illustrative INDUSTEC example shows how to evaluate quotation assistance without reducing evidence to reported time: the protocol connects perimeter, baseline, quality, adoption, capacity and margin before calculating a return.

• Bound the quotation process: trigger, variants, contributors, rework and final approval.
• Measure a representative baseline before deployment: active time, end-to-end delay, correction rate, margin and conversion rate.
• Design assistance around authorised sources, pricing rules, exceptions and explicit commercial approval.
• Track adoption, time, quality, incidents, released capacity and incremental margin separately.
• Reconcile units, period and population before publishing any gain or ROI.

The methodological lesson remains useful without a headline figure: quotation assistance may be relevant if both speed and quality improve, but the benefit must be established on the real perimeter and compared with the system’s full cost.

• An hour reported as “saved” is not automatically an hour of cash expenditure avoided.
• A faster quotation creates revenue only if the capacity is used and additional margin is attributable.
• A conversion rate should be compared across similar opportunities and a sufficient period.
• The investment decision rests on the company’s measured base, full costs and sensitivity of its own assumptions.

Chapter 8: a twelve-month roadmap

One year can establish a decision loop and several reliable uses, provided the pace reflects risk and data debt rather than promising the same maturity level to every business.

• Quarter 1 — see and choose: inventory, assessment, usage rule, baselines and prioritised portfolio.
• Quarter 2 — prepare and test: minimum data, architecture, training, controls and first pilot.
• Quarter 3 — decide and operate: conditional production, support, measurement and monthly review.
• Quarter 4 — consolidate and expand: common standard, targeted audit, tested reversibility and the next roadmap.

Roadmap governance fits on a short dashboard that connects each use to a decision, preventing a collection of indicators from replacing accountability.

• Value: net business outcome and attribution assumption.
• Use: active users and frequency across the target population.
• Quality: success on the evaluation set and human rework.
• Risk: incidents, exceptions, data and blocked actions.
• Cost: committed TCO, cost per result and forecast.
• Decision: continue, correct, extend or stop, with an owner and date.

Chapter 9: deciding the next level

AI maturity helps select the next investment that the organisation can absorb, evidence and govern while retaining control of its data, costs and decisions.

• Start with missing evidence at the current level.
• Frame a case whose baseline and result are measurable.
• Establish accountability and the stop procedure before autonomy.
• Compare infrastructure options on TCO, risk and reversibility.
• Expand only after a joint review of value, use, quality and risk.

From diagnosis to industrialisation

This white paper answers “where are we?”; the next volume, From PoC to Industrialisation, covers change management, AgentOps and production at scale.

• Read white paper no. 2 online.
• See the white-paper collection.

Junyr AI Maturity Audit

Junyr.eu’s current offer is a free thirty-minute audit that provides a position, the main obstacle to the next level and the first relevant initiative, followed by a one-page deliverable [6].

• Held by video with a Junyr network AI Transformer using a common framework.
• No commitment and no obligation to continue with an engagement or Junyr Suite.
• Designed for an initial decision, without promising certification, compliance or a complete roadmap.
• Book the AI Maturity Audit.

Sources and limitations

The following sources support the external claims retained here; method observations are presented as recommendations, and regulatory links should be reviewed whenever a high-stakes decision is made.

• [1] DGE / France Num, 2025 France Num Barometer, 11,021 businesses: 26% report using an AI solution. Read source
• [2] French Ministry for the Economy, Osez l’IA, 2030 target: 80% of SMEs and mid-caps using AI. Read source
• [3] KPMG, Global AI Pulse, 31 March 2026, n = 2,110 leaders from organisations with at least US$100 million in annual revenue: 64% report meaningful outcomes and 11% belong to the “AI leaders” cohort. Read source
• [4] European Union, Regulation (EU) 2024/1689 establishing the AI Act. Read source
• [5] European Union, Regulation (EU) 2026/1744 amending the AI Act, including Article 4 and the high-risk-system timetable. Read source
• [6] Junyr.eu, AI Maturity Audit offer, accessed 6 September 2026. Read source
• [7] ISO, ISO/IEC 42001:2023, artificial intelligence management system. Read source
• [8] ANSSI, security guidance and publications on post-quantum cryptography. Read source
• [9] U.S. Department of Justice, The Purpose and Impact of the CLOUD Act, April 2019. Read source
• [10] Hugging Face, Transformers: Quantization overview. Read source
• [11] European Commission, NIS2 Directive: securing network and information systems. Read source
• [12] European Commission, Data Act explained. Read source First published on 23 May 2026; revised on 6 September 2026, version 2.4.