Commissioning a custom AI business application for your local authority: public procurement and support

Commissioning custom software through public procurement is an exercise that many local authorities approach with some apprehension: how do you express the requirement without knowing development yourself? How do you draft a contract that protects the authority? What should you require on code ownership?

This article answers these questions practically, in the order they arise — from the initial idea through to maintaining the tool over time.

From idea to contract: the key steps

1. Identify the process to transform: what concrete business problem justifies the project?
2. Scope the functional requirement: what must the tool do, for whom, in what context, with what data?
3. Choose the appropriate form of contract: adapted procedure (MAPA), framework agreement, formalised procedure — depending on the estimated value and the duration.
4. Write the technical requirements document: describe the expected features, the technical constraints, the compliance obligations (GDPR, AI Act, RGAA accessibility), and the requirements on code ownership and reversibility.
5. Assess the bids and choose the provider: criteria of technical quality, working method, references, capacity to support over time.
6. Deliver the project in iterations: phased development with intermediate acceptance stages.
7. Go live and train the teams.
8. Maintain and evolve the tool: a maintenance and support (TMA) contract.

The most decisive phase — and the most often underestimated — is phase 2: scoping the requirement. This is where the quality of the contract, and ultimately the success of the project, is decided.

Scoping the requirement properly before the tender

A poorly scoped tender produces bids that cannot be compared, providers who underestimate the work, and cost overruns during delivery. Scoping the requirement does not mean knowing how to code — it means being able to answer these questions:

• What is the problem to solve? (not "I want an application", but "today this process costs us X hours a week and generates errors of type Y")
• Who are the users of the tool? (internal staff, members of the public, external partners — with which access levels)
• What data is processed? (nature, volume, sensitivity, retention)
• What are the compliance constraints? (GDPR, the AI Act if the tool includes AI, RGAA accessibility)
• What are the integration constraints? (existing systems the tool must communicate with)

Groupe Milestone offers an audit and scoping engagement ahead of drafting the contract: we help the authority formalise its requirement, produce the elements needed for the technical requirements document and anticipate the technical questions candidates will raise. This engagement can be contracted independently of the development, preserving the neutrality of the procedure.

Explore our Consulting & audit service.

Which form of contract for custom development?

The choice depends chiefly on the estimated value and the iterative nature of the project. A few general markers (to adapt to the thresholds in force and the specifics of your authority — consult your public buyer or your legal department):

• The adapted-procedure contract (MAPA) offers a degree of flexibility in the selection criteria and in the dialogue with candidates — often used for mid-sized projects.
• The framework agreement suits situations where needs are recurring or the scope evolves over time (successive developments, functional changes).
• The design-and-build contract combines the definition phase and the development phase within a single contract — relevant for complex projects.
• The competitive dialogue can be useful when the authority cannot define the technical requirement precisely on its own.

In every case, writing the technical requirements document remains the responsibility of the local authority. Groupe Milestone can help scope the requirement and inform the drafting — but we do not write the tender in the buyer's place.

Ownership of the code and data, and reversibility

This is one of the most important points — and one of the least formalised in local authorities' software development contracts. Here is what you should require:

• Ownership of the source code. The code developed under the contract must belong to the authority. This clause must appear explicitly in the technical requirements document and in the contract.
• Access to the sources. Require an accessible, documented code repository with version history.
• Technical documentation. Functional and technical documentation must be part of the contractual deliverables.
• Data reversibility. The authority's data must be exportable in a standard format at any time.
• No dependence on uncontrolled proprietary licences. Check that the licences of third-party components are compatible with public use.

At Groupe Milestone, these principles are built into our commitments by default: the authority remains the owner of its tool, its code and its data.

AI within the project, serving the business need

Bringing artificial intelligence into a custom tool does not change the logic of public procurement — but it adds specific requirements to anticipate.

On the regulatory side, the AI Act places obligations on authorities that deploy AI systems: transparency, human oversight and, for certain uses, enhanced documentation. The broadest obligations on high-risk systems apply from August 2026. For the detail: The AI Act: what local authorities need to know.

On the contractual side, if the tool draws on third-party AI models (via API or open-source components), the terms of use of those models must be checked — particularly on the confidentiality of the data sent to third-party services.

Groupe Milestone builds these questions in from the scoping phase. Explore our Automation & AI service.

After delivery: maintenance and lasting support (TMA)

A delivered tool is not a finished tool. A good maintenance and support (TMA) contract provides for:

• Corrective maintenance: fixing bugs and anomalies.
• Evolutionary maintenance: adding features, adapting to new business or regulatory rules.
• Preventive maintenance: updating technical components to avoid obsolescence and security flaws.
• Clear service levels (SLAs): response times according to the criticality of incidents.
• A training arrangement: supporting teams as they take up the tool and its changes.

At Groupe Milestone, maintenance and support is not just about fixing bugs. It is the continuation of the partnership: we follow the real-world use of the tool, identify the improvements that matter, and anticipate the regulatory constraints ahead.

Explore our Support / TMA service.

For local authorities in Nouvelle-Aquitaine and the Basque Country: Groupe Milestone in the Basque Country.