Ce que le développement logiciel du secteur public exige réellement

Le développement logiciel du secteur public n'est pas plus difficile parce que la technologie est plus avancée. Il est plus difficile parce que les contraintes sont non négociables, les modes de défaillance sont publics, et les personnes qui souffrent quand quelque chose se passe mal ne sont pas des clients payants qui peuvent partir. Ce sont des citoyens. Cela change chaque décision, de la structure de la base de données au pipeline de déploiement.

J'ai construit dans des environnements réglementés assez longtemps pour savoir que la plupart des équipes traitent la conformité comme une case à cocher en fin de parcours. Elles terminent le produit, puis demandent à un avocat ce qu'elles doivent ajouter. Cette séquence est l'erreur. La piste d'audit, les contrôles d'accès, la précision des calculs, la provenance des données : ce sont des décisions architecturales. Vous ne pouvez pas les ajouter après coup sans réécrire les parties qui comptent le plus.

Le plancher réglementaire est plus élevé que la plupart des fondateurs ne l'attendent

Aux États-Unis, OMB M-24-10 exige désormais que les fournisseurs de logiciels fournissent une documentation rigoureuse sur la sécurité de l'IA, la provenance des données et l'atténuation des biais avant que tout système d'IA « déterminant l'impact » puisse être déployé par une agence fédérale. Le formulaire d'attestation de développement logiciel sécurisé de CISA est une norme que les fournisseurs fédéraux doivent remplir. Ce ne sont pas des suggestions. Ce sont des portes d'approvisionnement. Si votre logiciel ne peut pas les satisfaire sur papier avant la signature d'un contrat, vous n'obtenez pas le contrat.

Le modèle est cohérent sur les marchés. L'approvisionnement du secteur public européen a longtemps exigé la résidence des données, la journalisation des audits et les évaluations de sécurité formelles. Au Cameroun, les systèmes de déclaration fiscale et financière doivent se conformer aux normes comptables OHADA. Les détails diffèrent. La discipline sous-jacente est la même : vous devez pouvoir montrer votre travail, à tout moment, à quelqu'un qui ne l'a pas construit et ne vous fait pas confiance.

C'est le vrai test. Non pas si le logiciel fonctionne aujourd'hui, mais si un régulateur peut reconstruire ce qu'il a fait il y a six mois.

La précision est une spécification, pas une métrique de qualité

Dans un produit SaaS, une erreur de calcul pourrait générer un ticket d'assistance. Dans une plateforme fiscale, la même erreur génère une pénalité, un différend juridique, ou un audit de l'agence qui a déployé votre logiciel. La tolérance est différente. Vous ne pouvez pas livrer « assez bon » et itérer.

Quand j'ai construit OptimalTax, une plateforme de déclarations fiscales automatisées pour le secteur public, la contrainte qui a façonné tout était la précision. Le système a atteint 99% de précision de calcul fiscal. Ce nombre ne venait pas de l'optimisme. Il venait de la construction du moteur de calcul séparément de l'interface utilisateur, du test par rapport aux résultats connus du processus manuel existant, et du traitement de chaque cas limite comme une exigence de spécification plutôt que comme un bug à corriger plus tard. Le modèle de données devait refléter la structure juridique du code fiscal, pas une version simplifiée qui était plus facile à interroger.

C'est la discipline qui sépare le travail du secteur public de la plupart du travail produit. Le domaine est la spécification. Vous ne pouvez pas simplifier le domaine pour rendre l'ingénierie plus facile.

La conformité aux audits doit être conçue dès le premier jour

Une piste d'audit n'est pas un fichier journal. Un fichier journal enregistre ce qui s'est passé. Une piste d'audit enregistre ce qui s'est passé, qui l'a autorisé, quel était l'état du système à ce moment, et si un processus automatisé a pris une décision qui a affecté une personne. Ce sont des exigences différentes, et elles ont des implications différentes pour votre modèle de données, votre stratégie d'approvisionnement en événements, et votre politique de rétention.

Je traite la conformité aux audits comme une préoccupation architecturale de première classe. Cela signifie :

• —Des journaux d'événements immuables qui enregistrent les transitions d'état, pas seulement l'état actuel
• —Des contrôles d'accès basés sur les rôles qui sont appliqués au niveau de la couche de données, pas seulement au niveau de la couche API
• —La versioning des calculs, afin que vous puissiez reproduire ce que le système a calculé à une date donnée en utilisant les règles qui étaient actives à ce moment
• —Une séparation claire entre le système d'enregistrement et le système de présentation

Rien de tout cela n'est exotique. Tout cela est du travail qui doit être défini et budgétisé avant la première ligne de code d'application. Les équipes qui le sautent passent plus de temps à le rétrofitter plus tard qu'elles n'auraient passé à le construire correctement au départ.

La plateforme de services financiers que j'ai construite pour un client fintech a suivi la même discipline, car les systèmes financiers et les systèmes du secteur public partagent la même exigence d'audit. Chaque transaction avait une chaîne de provenance. Les temps de réponse ont chuté de 30% en partie parce que le modèle de données était assez propre pour être interrogé efficacement. La correction et la performance ne sont pas en tension quand l'architecture est correcte.

Ce qui se casse quand vous traitez le travail du secteur public comme du travail produit

Le mode de défaillance le plus courant que je vois est une équipe qui construit un service destiné aux citoyens de la même manière qu'elle construirait une application grand public. Elles optimisent pour la conversion, simplifient le flux, et abstraient la complexité qui s'avère être légalement requise.

Un formulaire fiscal a des champs qui existent parce qu'une loi l'exige. Vous ne pouvez pas les supprimer parce qu'ils testent mal dans la recherche utilisateur. Un flux de conformité a des étapes qui existent parce qu'un régulateur les a mandatées. Vous ne pouvez pas les réduire en un seul écran parce que votre designer pense que l'UX est plus propre. Les contraintes du domaine ne sont pas négociables, et une équipe qui ne comprend pas le domaine prendra des décisions qui semblent sensées et qui sont en fait fausses.

C'est pourquoi je passe un temps considérable à la modélisation du domaine avant tout travail d'implémentation sur un engagement du secteur public. L'objectif est de comprendre la structure juridique et procédurale assez bien pour que le modèle de données la reflète fidèlement. Un modèle qui ne reflète pas le domaine produira des erreurs qui sont invisibles jusqu'à ce qu'un auditeur les trouve.

Le travail du système de conception en production que j'ai fait pour les clients réglementés suit la même logique. La cohérence dans un système de conception n'est pas une préférence esthétique. Dans un produit destiné au gouvernement, c'est une exigence d'accessibilité et de conformité juridique. Chaque composant est un contrat.

La décision qu'un fondateur doit prendre avant de commencer

Si vous construisez pour le secteur public, la décision que vous affrontez n'est pas quel framework utiliser ou comment structurer votre équipe. La décision est de savoir si vous êtes prêt à traiter le domaine comme la contrainte principale de chaque choix d'ingénierie.

Cela signifie ralentir au départ. Cela signifie investir dans l'expertise du domaine avant d'investir dans la vélocité. Cela signifie définir les exigences d'audit et de conformité dans le cadre de la phase architecturale, pas la phase QA. Cela signifie accepter que certaines simplifications qui seraient acceptables dans un produit grand public ne vous sont pas disponibles ici.

Les équipes qui réussissent dans le développement logiciel du secteur public sont celles qui prennent cette décision consciemment et tôt. Celles qui échouent sont généralement celles qui découvrent les contraintes après avoir déjà construit quelque chose qui ne peut pas les satisfaire.

Si vous êtes au point de décision maintenant, l'étude de cas OptimalTax est la preuve la plus directe de comment j'aborde ce travail. Si vous voulez discuter de ce que votre plateforme spécifique exige, commencez par le formulaire de contact ou explorez les modèles d'engagement pour trouver la portée appropriée pour où vous en êtes.