Digital government
Designing public digital services usable by the whole population, including offline and outside the capital.
The issue
The problem as it presents itself.
A public digital service is worth something only if it can be used by those who depend on it most. The real constraints are network coverage, the diversity of devices, the level of digital literacy, and the continuity of civil registries and reference data.
Intended outcome
What the organisation gets.
Services reachable from modest devices and slow networks, whose registries stay consistent and whose use does not depend on a single supplier.
Before committing
Four preliminary questions.
An organisation that cannot answer these questions does not yet have a programme: it has an intention. Formulating them costs less than discovering them mid-delivery.
- 01Has the service been tried by real users, on their own devices and their own network?
- 02What becomes of a procedure already started when the connection is lost mid-entry?
- 03Are your registries consistent across administrations, or does each department keep its own?
- 04Do you measure actual use of the service, or only the fact that it went live?
Our role
What we take on.
- Design of user journeys tested under real conditions.
- Consistent registries and reference data across administrations.
- Interoperability founded on open, published standards.
- Accessibility and design for constrained networks.
- Measurement of actual use, kept distinct from measurement of go-live.
Security
Principles applied.
- Protection of personal data through minimisation and separation.
- Authentication proportionate to the sensitivity of the service.
- Traceability of access to registries and civil-status data.
- Continuity of service when a component becomes unavailable.
Deployment
Available modes.
- On national infrastructure.
- In a hybrid environment, with degraded offline operation.
The mode depends on the organisation’s own sovereignty, continuity and classification requirements. It is settled before design, not after.
Division of operational responsibility
Framing
Konect 9 / organisation 3
Requirements, exit criteria and the reversibility plan are established.
Build
Konect 8 / organisation 4
The organisation’s teams take part in design, not in acceptance testing alone.
Go-live
Konect 5 / organisation 7
Operation is conducted jointly, against written procedures.
Supported operation
Konect 2 / organisation 10
The organisation operates; Konect steps in on request.
Autonomy
Client organisation, alone
The engagement ends. The system runs without outside assistance.
Transfer of skills
End of engagement.
Transfer of functional and technical control to the administration’s own teams, with documentation and ownership of the code held by the client.
Related domains.
Consultations · Pre-qualifications · Partnerships
Continue the conversation.
Detailed material — methodology, references, capability statement — is provided within a controlled framework, at the request of an identified organisation.