Définition opérationnelle
Ce que le concept recouvre — et ce qu’il ne recouvre pas.
Le protocole part des décisions à soutenir et distingue collecte, modélisation, validation, scénarios, gouvernance, export et coût de sortie. Un véritable comparatif exige des tests datés appliqués avec la même grille à chaque solution.
Autoriser une présélection seulement après un test documenté dont les données d’entrée, résultats attendus, écarts et conditions de sortie sont conservés.
Couverture fonctionnelle, transparence, tests, export, interopérabilité, coût total et dépendance.
Une interface convaincante peut masquer des transformations, priors ou règles d’allocation impossibles à auditer.
Cadre de décision
Une méthode qui rend les hypothèses auditables.
Écrire trois cas tests représentatifs et leurs résultats attendus avant toute démonstration éditeur.
Exécuter la même entrée dans chaque solution et conserver paramètres, transformations, diagnostics et exports.
Calculer licence, intégration, exploitation, compétences, migration et coût de sortie sur la même période.
Séparer capacités observées, déclarées et non évaluées, avec une date de contrôle et un responsable.
Paramètres non négociables
L’unité, l’horizon et le comparateur doivent être fixés avant le calcul.
Ces cinq paramètres déterminent ce que le résultat signifie réellement. S’ils changent pendant l’analyse, les scénarios ne sont plus comparables et la recommandation doit être recalculée.
Observation ou ressource identifiée par sa source, sa population, son unité, sa période, sa version et ses droits d’utilisation.
Indiquer date de collecte, fraîcheur pertinente pour la décision et cadence de révision ; une date récente ne corrige pas une définition inadéquate.
Comparer distributions et méthodes à périmètre homogène ; ne jamais traiter un benchmark externe comme une cible locale automatique.
Publier taille d’échantillon, dispersion, exclusions, transformations, biais de sélection et limites de reproductibilité.
Une ressource n’entre dans une décision que si sa provenance, son applicabilité et ses transformations peuvent être auditées.
Dossier de décision
Ce que le comité doit recevoir — au-delà d’un résultat central.
Le livrable doit permettre de refaire le raisonnement, de contester une hypothèse et de savoir quand la conclusion cesse d’être valable. Une valeur isolée, même précise, ne remplit pas cette fonction.
Préparer une évaluation vérifiable. Écrire les options réellement ouvertes, le statu quo et la personne responsable du choix.
Couverture fonctionnelle, transparence, tests, export, interopérabilité, coût total et dépendance. Préciser unité, numérateur, dénominateur, population et période.
Calculer licence, intégration, exploitation, compétences, migration et coût de sortie sur la même période. Conserver la même définition de coût et de résultat pour chaque option.
Séparer capacités observées, déclarées et non évaluées, avec une date de contrôle et un responsable. Rapporter les contrôles qui échouent aussi clairement que ceux qui réussissent.
Une interface convaincante peut masquer des transformations, priors ou règles d’allocation impossibles à auditer. Chiffrer l’impact d’une hypothèse trop optimiste et d’une décision retardée.
Révision trimestrielle. Définir le signal, le seuil et la date qui déclencheront maintien, correction ou arrêt.
Exemple chiffré
Exemple pédagogique de coût complet
Situation. Deux solutions fictives sont comparées uniquement pour illustrer la formule. A coûte 40 k€ et exige 80 jours d’intégration ; B coûte 70 k€ et 20 jours. Le jour interne est valorisé 700 €.
Calcul. Coût pédagogique de première année : A = 40 000 + 80 × 700 = 96 000 € ; B = 70 000 + 20 × 700 = 84 000 €.
Lecture. Cet exemple ne classe aucun logiciel réel. Auditabilité, maintenance et coût de sortie restent à mesurer avec un protocole daté.
Règles de décision
Quand considérer l’analyse comme suffisamment solide.
- Autoriser une présélection seulement après un test documenté dont les données d’entrée, résultats attendus, écarts et conditions de sortie sont conservés.
- Mesurer au minimum : Couverture fonctionnelle, transparence, tests, export, interopérabilité, coût total et dépendance.
- Condition de validation : Séparer capacités observées, déclarées et non évaluées, avec une date de contrôle et un responsable.
Limites
Ce que les données et la méthode ne permettent pas d’affirmer.
- Une interface convaincante peut masquer des transformations, priors ou règles d’allocation impossibles à auditer.
- Un repère sectoriel n’est pas une cible normative.
- Une donnée publique peut être documentée mais impropre à une décision locale.
Références bibliographiques
Les travaux qui fondent cette analyse.
- Peng, R. D. (2011), Science.
- Sculley, D. et al. (2015), « Hidden Technical Debt in Machine Learning Systems ».
- Wilkinson, M. D. et al. (2016), « The FAIR Guiding Principles for Scientific Data Management », Scientific Data.
- Peng, R. D. (2011), « Reproducible Research in Computational Science », Science.
Mise en pratique
Le canevas à produire pour décider
Décision · cible · objectif · horizon · options · contraintes · interactions · unité économique · preuve · seuil de révision. Le support associé conserve aussi les hypothèses, limites, version et date de réexamen.
Voir l’outil ou le support associé →