Le développement logiciel IA du secteur public crée des services assistés par modèle dans un mandat public et un processus administratif définis. Il associe ingénierie produit, accessibilité, gouvernance de l’information, décisions traçables, égalité d’accès, responsabilité humaine, recours, preuves d’achat et exploitation durable. L’IA traite une tâche interprétative bornée, tandis que l’autorité, le registre officiel et les décisions importantes restent maîtrisés.
Un assistant utile peut devenir une décision automatique cachée si sa recommandation est toujours acceptée ou inscrite sans distinction au dossier. Un service numérique peut être efficace pour la moyenne et exclure les personnes handicapées, peu à l’aise dans la langue, mal connectées ou confrontées à une situation complexe. Les systèmes publics survivent aux pilotes et fournisseurs. Sans données, évaluations, réglages, interfaces et savoir d’exploitation transférables, une innovation courte crée une dépendance longue.
Concevez depuis la personne affectée et la décision publique responsable. Établissez mandat, finalité, utilisateurs, pouvoir, registre, notification et correction avant le modèle. Séparez assistance, recommandation et décision officielle dans les données et l’interface. Offrez une voie accessible, assistée ou sans IA lorsque nécessaire. Évaluez diversité des cas et pannes. Achetez les preuves, documents, portabilité et capacité de sortie nécessaires au-delà d’un modèle ou fournisseur.
Responsabilité
Construire le produit autour du dossier de décision publique
Commencez par les états administratifs importants. Une personne fournit des informations; l’autorité vérifie les faits; le logiciel classe ou résume; un agent prépare une recommandation; un rôle habilité décide ou communique officiellement. Stockez ces événements séparément. Un résumé du modèle ne devient pas un fait vérifié. Une recommandation n’écrase pas la décision. Le dossier identifie sources, versions, règles, modifications et acteur responsable au niveau exigé par le service.
Concevez explication et correction en même temps. La personne a besoin d’un langage adapté au processus, pas d’un exposé technique sur le modèle. Montrez les informations utilisées, l’autorité, la conséquence, la correction possible et la revue humaine. N’inventez jamais une justification après coup. Si des règles déterministes produisent la décision, expliquez ces règles et faits dans les limites permises. Si l’IA n’a fait que préparer, dites-le précisément et séparez le pouvoir.
- Séparer preuve, inférence, recommandation et décision.
- Nommer registre de référence et rôle responsable.
- Garder source et version des sorties importantes.
- Concevoir explication et correction avec le processus.
- Ne jamais inventer une justification après la décision.
Accessibilité et inclusion
Évaluer si les personnes peuvent achever tout le service
L’accessibilité ne se prouve pas en testant seulement une fenêtre de dialogue. Suivez le parcours: trouver le service, comprendre l’éligibilité, s’authentifier, fournir les pièces, revoir les extractions, recevoir la notification, corriger et demander de l’aide. WCAG 2.2 donne des règles testables pour le contenu web, mais une page conforme peut mener à une issue administrative inaccessible. Incluez technologies d’assistance, langage clair, clavier, délais, alternatives documentaires et aide humaine.
Construisez les cohortes depuis la population réelle et les difficultés prévisibles. Testez langues, noms atypiques, historiques incomplets, besoins d’accessibilité, faible aisance numérique, représentation et cas hors standard. Mesurez qui doit soumettre de nouveau, attendre, être orienté ou corrigé. Le but n’est pas d’inférer sans autorité des attributs sensibles, mais de trouver les résultats inégaux par une évaluation légitime et une gouvernance qualifiée.
| Niveau | Question | Preuve |
|---|---|---|
| Accès | Les personnes entrent-elles et comprennent-elles ? | Tests accessibilité et langue |
| Dossier | Faits et identité sont-ils corrects ? | Parcours représentatifs |
| Décision | Pouvoir et motifs sont-ils justes ? | Audit du dossier et de la revue |
| Recours | Une erreur peut-elle être corrigée ? | Issues de correction et recours |
| Continuité | Le service résiste-t-il aux pannes ? | Exercice de repli |
Contrôle public
Acheter la capacité d’inspecter, d’exploiter et de partir
L’achat public d’IA doit demander des preuves opérationnelles, pas une promesse générale. Définissez données d’évaluation et acceptation, cas difficiles, notification de changement, incidents, usage des données, sécurité, accessibilité, performance, audit et continuité. Les orientations fédérales suisses soulignent une IA centrée sur l’humain, transparente, traçable et responsable; le Contrôle fédéral des finances organise l’audit autour de la fiabilité, de l’économie et des compétences. Les devoirs précis dépendent du cas.
Précisez les actifs de transition avant signature. L’autorité peut avoir besoin de source ou séquestre, interfaces, réglages, invites, jeux d’évaluation, schémas, provenance, journaux, procédures, infrastructure, formation et formats d’export. Les droits et licences sont explicites. Testez si une deuxième équipe comprend l’architecture et restaure un service représentatif. Une clause de sortie théorique est faible si les données, le comportement ou le savoir ne peuvent être transférés.
- Acheter comportement mesurable et preuves, pas une étiquette IA.
- Contrôler usage fournisseur et changement de comportement.
- Exiger une exploitation accessible et un repli sûr.
- Définir contractuellement actifs portables et droits.
- Répéter la transition avant la fin du contrat.
Ce qui caractérise un bon résultat
Résultats concrets pour développement logiciel IA secteur public
- Le cas d’usage possède finalité publique, mandat, personnes affectées, propriétaire et usages interdits.
- Population et agents distinguent l’assistance du modèle de la décision officielle et de son autorité.
- Les sorties importantes portent source, modèle, règle, relecteur, version et issue administrative.
- L’accessibilité et les besoins d’assistance sont testés sur le parcours complet et pas uniquement l’écran.
- L’évaluation couvre langues, situations, cas difficiles, attaques, pannes et résultats inégaux.
- Les personnes reçoivent une explication adaptée, peuvent corriger leurs données et obtenir une vraie revue.
- L’exploitation continue de façon sûre si modèle, fournisseur, intégration ou voie automatique tombe.
- L’autorité peut auditer, maintenir, remettre en concurrence, migrer ou retirer le service avec ses actifs.
Modèle opératoire
Comment exécuter le travail
- 01
Établir mandat et résultat du service
Définissez base juridique et métier avec les responsables qualifiés, finalité, utilisateurs, personnes affectées, conséquence et registre de référence. Cartographiez le service actuel, y compris assistance et hors ligne. Décidez si l’IA est utile et ce qui reste interdit.
- 02
Concevoir le dossier responsable
Séparez preuves soumises, faits vérifiés, sortie du modèle, recommandation agent et décision officielle. Définissez qui voit, corrige et change chaque état. Gardez source, règle, version, motif et autorité pour le traitement, l’explication et l’audit.
- 03
Construire un comportement inclusif et borné
Utilisez des cas de langue, accessibilité et administration représentatifs. Validez entrées et sorties, gardez la provenance et limitez les outils. Concevez notifications claires, interactions accessibles, correction, abstention et passage à un agent qualifié.
- 04
Piloter tout le service public
Testez les voies numériques et assistées avec preuves absentes, situations atypiques, abus, pics et pannes. Mesurez issues acceptées, erreurs inégales, travail des agents, charge des personnes et reprise plutôt que le seul score du modèle.
- 05
Exploiter et préserver le contrôle public
Versionnez le comportement, surveillez résultats, échantillonnez les cas et exercez le repli. Maintenez documentation, évaluation, provenance, interfaces, déploiement et exports. Testez changement de fournisseur et retrait sûr avant l’urgence.
Évaluation
Les questions qui changent la décision
- Quel mandat et quel résultat public justifient l’IA dans ce service précis ?
- Le modèle assiste-t-il un agent, recommande-t-il une issue ou façonne-t-il une décision officielle ?
- Quel registre fait foi et comment une personne inspecte-t-elle ou corrige-t-elle les faits pertinents ?
- Quels groupes, langues, handicaps et cas complexes exigent leur propre évaluation ?
- Quelle voie accessible existe pour une personne qui ne peut pas utiliser le canal automatisé ?
- Quelle explication et quelle revue humaine sont utiles au point réel de conséquence ?
- Quelles données, traces et accès fournisseur sont nécessaires et comment leur but est-il imposé ?
- L’autorité peut-elle changer de modèle ou d’opérateur sans perdre service, preuves et savoir ?
Modes d’échec
Où les équipes perdent le contrôle
Une recommandation aux agents peut devenir décision automatique par acceptation systématique.
Les données administratives historiques peuvent reproduire exclusion, incohérence ou biais de contrôle.
Un modèle de langage peut inventer une raison différente du mécanisme officiel.
Une correction seulement en ligne peut exclure la personne déjà touchée par l’inaccessibilité.
Une bonne moyenne peut cacher une erreur grave pour un petit groupe linguistique ou de cas.
Des informations publiques peuvent se mêler aux dossiers protégés dans la recherche ou les journaux.
Une interface conversationnelle peut suggérer un pouvoir ou un droit hors du mandat.
Le repli manuel peut manquer de ressources au pic ou pendant la panne du fournisseur.
Un contrat peut donner accès au logiciel sans jeux d’évaluation, export ni savoir opératoire.
Le pilote peut compter des clics agents économisés tout en déplaçant la charge vers la population.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- issue de service acceptée par famille de cas et groupe utilisateur
- correction importante, recours, inversion et dossier non résolu
- sorties fondées et non fondées entrant dans le dossier officiel
- défauts d’accessibilité et achèvement par la voie assistée
- erreur, abstention et escalade par langue et situation pertinente
- temps de la personne, contacts répétés et preuves redemandées
- revue, dérogation, reprise et effort d’exception des agents
- disponibilité du repli, croissance du retard et récupération
- changement de comportement par version et fournisseur
- délai et complétude d’un exercice de transition modèle, données et opérateur
Questions
Questions fréquentes
Qu’est-ce qui distingue le développement IA du secteur public ?
Il doit respecter mandat public, dossier administratif faisant foi, accessibilité, responsabilité humaine, correction utile, preuves d’achat, longue durée de service et capacité de l’autorité à auditer, transférer ou retirer le système.
Une autorité peut-elle utiliser l’IA pour décider ?
La réponse dépend du mandat, du droit, du processus et de la conséquence. L’ingénierie ne présume rien. Elle distingue assistance et pouvoir officiel, conserve le dossier et soutient revue, notification et recours requis.
Comment tester l’accessibilité d’un service public IA ?
Testez tout le parcours numérique et assisté avec les utilisateurs, langues et technologies pertinents, y compris identité, preuves, revue, notifications, correction et repli. La seule conformité de l’écran ne suffit pas.
Comment éviter la dépendance à un fournisseur d’IA ?
Définissez données, interfaces, réglages, évaluations, traces, documentation, licences, procédures et appui de transition portables dans le marché, puis exercez la restauration avec une autre équipe avant l’urgence.
Sources
Sources primaires
- Stratégie d’utilisation des systèmes d’IA dans l’administration fédérale Chancellerie fédérale suisse
- Guide relatif à l’audit de l’intelligence artificielle au sein de l’administration fédérale Contrôle fédéral des finances
- Règles pour l’accessibilité des contenus Web 2.2 World Wide Web Consortium
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→