Solutions

Logiciels métiers

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

Métiers assemblés
Logiciels et systèmes

L’enjeu

La question n’est pas progiciel ou spécifique, mais où se situe la spécificité.

Peu d’organisations ont besoin d’un système 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 déjà.

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

Partout ailleurs, il produit une dépendance. Un logiciel livré sans documentation d’architecture, sans jeu d’essai exécutable 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.

Où se trouve la spécificité, schéma de principe

01Processus observé
Tel qu’il est exécuté. Un logiciel fidèle au document et étranger à la pratique est contourné dès la mise en service.
02Part spécifique
Ce qui distingue l’organisation, et que rien du marché ne couvre. C’est cela qui se construit.
03Part commune
Ce qui repose sur l’existant. Peu d’organisations ont besoin d’un système entièrement sur mesure.
04Intégration
Interfaces documentées, formats convenus, journalisation permettant de rapprocher deux systèmes qui divergent.
05Reprise des données
Les anomalies de l’existant s’arbitrent avec ceux qui les ont produites, jamais par le prestataire seul.
06Autonomie
Dépôt accessible, environnement reconstructible, suites de tests exécutables, équipe formée.
Schéma de principe. La question n’est pas progiciel ou sur mesure : c’est où se trouve la spécificité.Ordre de grandeur : la part réellement spécifique d’un logiciel métier, une fois le commun identifié. Elle se mesure au cadrage, et elle surprend presque toujours.

Résultat

Ce que vous obtenez

Une application en service, dont le code est déposé chez vous, dont l’environnement se reconstruit, dont les jeux d’essai permettent à une autre équipe de vérifier qu’elle n’a rien cassé, et dont les données sont hébergées là où vous l’avez décidé.

Périmètre

Ce que la solution comprend

Cadrage
Relevé des processus réels et non des processus décrits, 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.
Développement
Architecture documentée, livraisons par incréments mises entre les mains d’utilisateurs réels, 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 explicite des erreurs et des rejets, journalisation permettant le rapprochement de deux systèmes qui divergent.
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.
Restitution et décision
Indicateurs définis avec ceux qui décident, sources tracées jusqu’à la donnée d’origine, écarts et incertitudes affichés plutôt que lissés.
Exploitation et transfert
Hébergement sur infrastructure du client ou souveraine, supervision, sauvegardes éprouvées, documentation d’exploitation, formation et transfert progressif de la responsabilité.

Déroulement

Comment elle se conduit

  1. 01

    Observation

    Le processus s’observe avant de se spécifier. Un logiciel conforme au document et étranger à la pratique est contourné dès la mise en service.

  2. 02

    Premier périmètre en service

    Un périmètre restreint est mis en service tôt, puis étendu. Cela réduit le risque davantage qu’un calendrier long conduit d’une seule traite.

  3. 03

    Reprise et bascule

    Les anomalies de l’existant sont arbitrées par ceux qui les ont produites, jamais par le prestataire seul. La bascule est planifiée avec sa fenêtre et sa procédure de retour arrière.

  4. 04

    Autonomie

    Formation, documentation, dépôt de code à jour et jeux d’essai exécutables. Le périmètre d’autonomie est arrêté par écrit en fin de programme.

Engagements

Ce qui se vérifie à la réception

Ces engagements sont opposables. Repris dans une consultation, ils écartent les réponses qui ne tiennent pas, y compris la nôtre si elle ne les tient pas.

  • Le code est déposé chez le client dès la première livraison, avec une procédure de construction reproductible.
  • La documentation d’architecture et d’exploitation est produite au fil du projet, jamais rédigée après la réception.
  • Des jeux d’essai automatisés, exécutables par le client, accompagnent chaque livraison.
  • Les livraisons intermédiaires sont mises entre les mains d’utilisateurs réels, sans attendre une réception unique.
  • Les règles de reprise de données et les contrôles de cohérence sont écrits et chiffrés avant la bascule.
  • La localisation des données et le cadre juridique applicable sont documentés.
  • La clause de réversibilité décrit ce qui est remis, dans quel format et dans quel délai.

Avant d’engager

Questions à trancher en interne

Une organisation qui ne sait pas répondre à ces questions n’est pas prête à lancer le programme. Le lui dire vaut mieux que de lui vendre une étude.

  • Quelle partie du processus vous distingue réellement, et laquelle est commune à votre secteur ?
  • Qui connaît le processus tel qu’il est exécuté, et sera-t-il disponible pendant le projet ?
  • Dans quel état sont les données à reprendre, et qui arbitrera leurs anomalies ?
  • Quel périmètre peut être mis en service en premier sans attendre le reste ?
  • Quelle équipe interne reprendra l’exploitation, et de quelle autonomie a-t-elle besoin ?
  • Où les données doivent-elles résider, et pour quelle raison ?

Preuve

Ce que nous avons livré sur ce périmètre

Toutes les réalisations

Consultations · Préqualifications · Partenariats

Parlons du périmètre réel.

Décrivez le site, la contrainte dominante et l’échéance. Nous indiquerons ce qui relève d’une étude préalable et ce qui peut être engagé directement.