Développement logiciel sur mesure

Un logiciel n’a de valeur que si vos équipes peuvent le reprendre.

Métier de rattachement: Logiciels et systèmes

Le problème

La question n’est pas de choisir entre un progiciel et un développement, mais de savoir où se situe la spécificité.

La plupart des organisations n’ont pas besoin d’un logiciel entièrement spécifique. Elles ont besoin qu’une partie précise de leur activité — celle qui les distingue, ou celle qu’aucun éditeur ne couvre — soit outillée correctement, et que le reste s’appuie sur ce qui existe.

Un développement spécifique se justifie quand le processus est réellement propre à l’organisation, quand la contrainte d’intégration avec l’existant est plus lourde que la fonction elle-même, ou quand la souveraineté sur les données et le code interdit une solution hébergée hors du cadre applicable.

Dans tous les autres cas, il produit une dépendance. Un logiciel écrit sans documentation d’architecture, sans jeu d’essai et sans équipe formée appartient de fait à celui qui l’a écrit, quelle que soit la clause de propriété intellectuelle inscrite au contrat.

Ce qui rend un logiciel reprenable, schéma de principe

01Observation: Le processus réellement exécuté, et non celui que décrivent les documents.
02Incrément livré: Mis entre les mains d’utilisateurs réels, plutôt qu’une recette unique à la fin.
03Intégration: Interfaces documentées, formats convenus, traitement explicite des erreurs et des rejets.
04Bascule: Fenêtre, point de non-retour et procédure de repli, écrits avant la mise en service.
05Suite de tests: Exécutable par le client. C’est elle qui permet à une autre équipe de vérifier qu’elle n’a rien cassé.
06Dépôt et documentation: Code accessible dès la première livraison, environnement reconstructible, documentation d’architecture.

Schéma de principe. Le trait accentué est le chemin de la réversibilité, qui se décide au premier jour et pas à la sortie.Ordres de grandeur de conduite. La cadence de livraison et le taux de couverture sont des cibles ; elles se règlent au premier incrément, pas au contrat.

Périmètre

Ce que la prestation recouvre

Cadrage: Relevé des processus réels et non des processus décrits, identification des acteurs, arbitrage entre ce qui est repris d’une solution existante et ce qui est développé, périmètre de la première mise en service.
Conception et développement: Architecture documentée, développement par incréments livrés et éprouvés, revues de code, jeux d’essai automatisés, gestion des versions accessible au client.
Intégration: Interfaces documentées avec les systèmes en place, formats d’échange arrêtés, gestion des erreurs et des rejets, journalisation des échanges pour le rapprochement.
Reprise de données: Analyse de la qualité de l’existant, règles de transformation écrites, contrôles de cohérence chiffrés, reprises d’essai successives avant la reprise définitive.
Recette et mise en service: Recette conduite par les utilisateurs sur des cas réels, formation, bascule planifiée avec procédure de retour arrière, accompagnement des premières semaines.
Exploitation et transfert: Hébergement sur infrastructure du client ou souveraine, supervision, sauvegardes éprouvées, documentation d’exploitation, formation des équipes et transfert progressif de la responsabilité.

Situations

Situations les plus fréquentes

Processus propre à l’organisation: Aucun éditeur ne couvre le processus, ou le couvre au prix d’une adaptation plus coûteuse que le développement. Le spécifique est alors la solution la plus économique.
Intégration entre systèmes hétérogènes: Plusieurs systèmes rendent chacun un service utile mais ne communiquent pas. Le développement porte sur les interfaces et la cohérence des données, pas sur une refonte.
Remplacement d’un outil non maintenu: Un outil interne fonctionne, personne ne sait plus le modifier, et son auteur a quitté l’organisation. La reprise commence par la reconstitution des règles de gestion.
Exigence de souveraineté: Les données ne peuvent pas quitter un cadre juridique donné. Le développement s’accompagne d’un hébergement maîtrisé et d’une réversibilité documentée.

Exigences

Ce qu’il faut exiger, de nous comme d’un autre

Ces exigences valent quel que soit le prestataire retenu. Reprises dans une consultation, elles écartent les réponses qui ne tiennent pas.

La propriété du code source et son dépôt effectif chez le client, dès la première livraison et non à la fin.
Une documentation d’architecture et d’exploitation produite au fil du projet, pas rédigée après la réception.
Des jeux d’essai automatisés, exécutables par le client, qui rendent une reprise par une autre équipe possible.
Des livraisons intermédiaires mises entre les mains d’utilisateurs réels, pas une réception unique en fin de parcours.
Les règles de reprise de données écrites et les contrôles de cohérence chiffrés, avant la bascule.
Une clause de réversibilité décrivant ce qui est remis, dans quel format et dans quel délai.
La formation des équipes internes, avec un périmètre d’autonomie explicite en fin de projet.

Écueils

Erreurs fréquentes, et ce qu’elles coûtent

Spécifier avant d’observer: Le processus décrit dans les documents diffère du processus réel. Un logiciel conforme au document et étranger à la pratique est contourné dès la mise en service.
Livrer une seule fois, à la fin: L’écart entre le besoin et le produit se découvre à la recette, quand il coûte le plus cher à corriger. Des livraisons régulières transforment cet écart en correction ordinaire.
Traiter la reprise de données comme une tâche technique: C’est une tâche métier : les anomalies de l’existant doivent être arbitrées par ceux qui les ont produites. Confiée au seul prestataire, elle produit des décisions arbitraires découvertes après la bascule.
Repousser l’exploitation à la mise en service: Supervision, sauvegardes, journalisation et procédure de restauration se conçoivent avec l’application. Ajoutés ensuite, ils sont incomplets, et c’est le premier incident qui le révèle.

Questions

Questions posées avant de consulter

Comment savoir si un développement spécifique se justifie ?

En comparant le coût d’adaptation d’une solution existante à celui d’un développement, sur la durée de vie attendue et non à l’achat. Le spécifique se justifie lorsque le processus est réellement propre à l’organisation, lorsque l’intégration pèse plus lourd que la fonction, ou lorsque la souveraineté sur les données interdit une solution hébergée hors du cadre applicable. Dans les autres cas, l’adaptation d’un progiciel coûte moins.

À qui appartient le code produit ?

Au client, et la clause seule ne suffit pas. La propriété se matérialise par un dépôt de code accessible au client dès la première livraison, une documentation d’architecture, des jeux d’essai exécutables et une procédure de construction reproductible. Sans ces quatre éléments, la propriété est formelle et la dépendance reste entière.

Combien de temps dure un projet de ce type ?

La durée dépend moins de la taille du logiciel que de la disponibilité des personnes qui connaissent le processus et de l’état des données à reprendre. Un périmètre restreint mis en service tôt, puis étendu, réduit le risque davantage qu’un calendrier long conduit d’une seule traite.

Comment intégrer le logiciel à des systèmes existants ?

Par des interfaces documentées, avec des formats d’échange arrêtés et une gestion explicite des erreurs et des rejets. Ce qui coûte n’est pas l’échange nominal mais le traitement des cas d’exception, et la capacité à rapprocher les deux systèmes lorsqu’ils divergent. Cette journalisation se conçoit dès l’origine.

Que se passe-t-il si nous changeons de prestataire ?

Rien, si la réversibilité a été traitée pendant le projet plutôt qu’à sa fin. Elle suppose un dépôt de code à jour, une documentation d’exploitation, un environnement reconstructible et des jeux d’essai qui permettent à une nouvelle équipe de vérifier qu’elle n’a rien cassé. C’est une exigence à formuler au premier jour, parce qu’elle change la manière de construire.

Faut-il héberger l’application chez le client ?

Le critère est la sensibilité des données, le cadre juridique applicable et la capacité de l’organisation à exploiter une infrastructure. L’hébergement sur l’infrastructure du client garde la maîtrise et impose une exploitation ; l’hébergement souverain externalisé décharge l’exploitation en conservant le cadre. Les deux se documentent, y compris la localisation effective des données.

Preuve

Où nous l’avons mis en œuvre

Gouvernement et administration publique2023
Administration publique — plateforme de traitement des demandes
Dématérialisation d'un service recevant du public, conçue pour rester utilisable en connexion instable et hors capitale.
Guichets déployés
9
Mois du programme
11
Référence KP-2023-005