Choisir entre un SaaS et une application métier sur mesure revient à comparer des trajectoires, pas seulement un prix d’abonnement. Un SaaS est souvent pertinent si le processus est standard, si les équipes acceptent d’adapter leurs habitudes, et si l’outil s’intègre correctement au SI. Le sur mesure devient intéressant dès que le processus est réellement différenciant (source de marge, de qualité, de conformité), ou quand l’entreprise passe son temps à contourner un outil générique.

La grille de décision (DAF/COO/IT)

• Différenciation métier : l’outil porte-t-il un savoir-faire ou un enchaînement d’étapes unique ? Si oui, le sur mesure protège mieux la valeur.
• Intégrations et flux : si l’on dépend de nombreuses intégration API (ERP, CRM, BI, SSO, GED), un SaaS peut vite devenir un puzzle de connecteurs, de limites d’API et de synchronisations fragiles.
• TCO logiciel : comparer le coût total, incluant paramétrage, licences, montée en gamme, accompagnement, run, support, coûts de non-qualité (erreurs, retards) et coûts de changement.
• Risque fournisseur : dépendance à une roadmap, à une politique tarifaire, à une disponibilité d’API, à une localisation des données.
• Réversibilité : facilité d’export, format de données, possibilité de migrer.

Un tableau de comparaison utile

L’objectif n’est pas de trancher « par principe », mais de documenter une décision buy vs build défendable, avec hypothèses et risques explicités.

Un projet de développement sur mesure entreprise dérape souvent quand le besoin est exprimé en fonctionnalités vagues (« un tableau de bord », « un workflow ») plutôt qu’en résultats métier observables. Le cadrage doit donc partir des irritants opérationnels et aboutir à un MVP logiciel testable, avec des critères d’acceptation concrets.

Du problème à la portée du MVP

• Cartographier le processus réel : acteurs, étapes, exceptions, points de contrôle, données manipulées, irritants (ressaisies, validations, retours arrière).
• Définir l’objectif : ce qui doit être vrai après le MVP (ex. une étape supprimée, une validation tracée, une donnée fiabilisée). Éviter les objectifs purement techniques.
• Délimiter le périmètre : ce que le MVP fait, et surtout ce qu’il ne fait pas (hors périmètre assumé).

User stories et critères d’acceptation

Rédiger des user stories orientées rôle et valeur :

• En tant que gestionnaire, je veux valider une demande selon des règles, afin de réduire les allers-retours.

Associer des critères d’acceptation vérifiables :

• états possibles et transitions
• règles de validation
• notifications attendues
• données obligatoires et contrôles de cohérence

La définition de « terminé »

Pour éviter l’effet tunnel, définir une Definition of Done incluant :

• tests (au minimum sur les scénarios critiques)
• documentation utilisateur minimale
• suivi des erreurs et journalisation (même simple)
• déploiement reproductible

Un MVP réussi n’est pas « petit » par nature : il est suffisamment étroit pour être livré vite, et suffisamment utile pour être adopté et mesurer la valeur.

L’intégration est l’endroit où une application métier sur mesure crée le plus de valeur… ou le plus de fragilité. Dès le cadrage, il faut décider quelles données sont maîtres (source of truth), comment elles circulent, et comment on évite les doublons et les divergences.

API et contrats d’échange

• Contrats : définir les objets échangés, leurs champs, règles de validation, et les codes d’erreur.
• Versioning : anticiper que les API évoluent (la vôtre ou celles des tiers). Prévoir une stratégie de compatibilité.
• Idempotence et reprise : la synchronisation doit tolérer les doublons d’appels et savoir reprendre après incident.

SSO et identité

Le SSO (SAML, OIDC) évite de multiplier les mots de passe et simplifie l’onboarding/offboarding. Points à cadrer :

• mapping des rôles et groupes
• comportement en cas de compte désactivé
• gestion des comptes de service

Qualité des données et gouvernance

Une automatisation processus ne résout pas une donnée incohérente. Mettre au clair :

• propriétaire de la donnée (qui la crée, qui la valide)
• règles de complétude et formats
• cycle de vie (archivage, suppression)

Traçabilité

Même sans exigences réglementaires particulières, la traçabilité protège l’entreprise :

• journal des actions (création, modification, validation)
• historique des statuts
• corrélation entre événements (utile en support)

En pratique, une bonne intégration SI réduit les ressaisies et rend les écarts visibles. Cela conditionne directement l’adoption : si l’outil « ment » sur les données, les équipes reviennent aux fichiers parallèles.

La sécurité applicative ne doit pas être un lot final. Sur un développement sur mesure, les choix initiaux (authentification, modèle d’autorisations, stockage, logs) déterminent la surface de risque et la capacité à réagir en cas d’incident.

Accès et autorisations

• Principe du moindre privilège : chaque rôle n’a accès qu’à ce dont il a besoin.
• Séparation des tâches : éviter qu’une même personne puisse initier et valider une action sensible sans contrôle.
• Gestion du cycle de vie : création, modification, désactivation des comptes, et traitement des comptes « orphelins ».

Journalisation utile (et exploitable)

Journaliser ne signifie pas tout enregistrer, mais capturer ce qui aide à comprendre :

• qui a fait quoi, quand, sur quel objet
• actions d’administration
• tentatives d’accès refusées

Veiller à ne pas enregistrer de secrets (mots de passe, tokens) dans les logs.

Sauvegardes, restauration, continuité

Une sauvegarde sans test de restauration est un pari. Cadrer :

• périmètre sauvegardé (base, fichiers, configurations)
• fréquence adaptée au métier
• procédure de restauration (qui fait quoi, dans quel ordre)

Conformité et bonnes pratiques

Sans promettre une « conformité automatique », s’aligner sur des référentiels reconnus aide à structurer :

• OWASP Top Ten et OWASP API Security pour les risques applicatifs
• NIST Cybersecurity Framework pour l’approche gouvernance
• ISO/IEC 27001 comme repère d’un système de management de la sécurité

Enfin, intégrer la sécurité au backlog : menaces principales, mesures, et critères d’acceptation sécurité (contrôles d’accès, validation des entrées, protection contre les attaques courantes).

Un outil sur mesure rentable est un outil qui tient dans le temps. Cela suppose de traiter l’exploitation comme un produit : supervision, mises à jour, incidents, et attentes de service. Trop souvent, l’application est livrée « finie », puis laissée sans propriétaire opérationnel.

Choisir un modèle d’hébergement

Trois questions structurantes :

• où sont les données (localisation, exigences internes, dépendances)
• qui opère (équipe interne, prestataire, mix)
• comment on déploie (processus reproductible, environnements)

Infogérance applicative

L’infogérance applicative n’est pas qu’un serveur : elle couvre la chaîne de run.

• gestion des incidents et demandes
• corrections et évolutions mineures
• gestion des accès d’exploitation
• suivi de la dette technique

Monitoring et observabilité

Pour réduire le temps de diagnostic :

• métriques (latence, taux d’erreur, saturation)
• alerting (seuils, escalade)
• tableaux de bord partagés (IT et métier)

SLA et attentes réalistes

Définir un SLA utile signifie préciser :

• plages de service
• délais de prise en charge et de résolution cibles selon la criticité
• procédures de contournement côté métier

Enfin, prévoir la gestion des dépendances (services tiers, API externes). Une application bien monitorée permet d’objectiver les incidents et d’éviter les débats stériles sur « qui est en cause ».

Un projet sur mesure échoue rarement par manque de bonne volonté ; il échoue par manque de mécanismes de contrôle. Réduire le risque, c’est multiplier les points de vérité : jalons clairs, démonstrations régulières, et critères de recette alignés sur les besoins.

Jalons orientés preuves

Remplacer les jalons « documents » par des jalons « preuves » :

• prototype de parcours critique
• première intégration API en bout en bout
• scénario métier complet en environnement de test

Pilotage et gouvernance

• sponsor métier responsable de la valeur
• responsable produit (priorisation, arbitrage)
• référent IT (intégration, sécurité, exploitation)

Éviter la gouvernance « comité qui décide tard ». Les arbitrages doivent être fréquents et documentés.

Recette : rendre l’acceptation objective

Construire un plan de recette basé sur :

• cas nominaux et exceptions
• données de test représentatives
• critères d’acceptation issus des user stories

La recette doit inclure les aspects non fonctionnels essentiels : droits, logs, performance perçue, reprise sur erreur.

Documentation et transfert

Documenter ce qui permet de maintenir :

• architecture et dépendances
• procédures de déploiement
• runbook (incidents fréquents, actions)

Réversibilité dès le départ

La réversibilité n’est pas un add-on :

• exports de données exploitables
• schéma et dictionnaire de données
• stratégie de remplacement (progressive si possible)

Ces garde-fous protègent budget et délais, mais surtout l’adoption : un outil livré sans recette ni exploitation finit souvent contourné, même s’il est « fonctionnel ».

Cette checklist sert de filet de sécurité pour cadrer et lancer un développement sur mesure entreprise sans multiplier les angles morts. Elle peut être utilisée en atelier avec le métier, l’IT et la finance.

Valeur et périmètre

• Clarifier le processus cible (étapes, acteurs, exceptions).
• Formuler l’objectif du MVP en termes de résultat métier observable.
• Écrire ce qui est explicitement hors périmètre.

Produit (MVP)

• Décliner le besoin en user stories priorisées.
• Définir des critères d’acceptation testables.
• Définir la Definition of Done (tests, déploiement, minimum de doc).

Données et intégration

• Lister les systèmes sources et les données maîtres.
• Définir les contrats d’API et les règles de synchronisation.
• Prévoir un plan de qualité de données (contrôles, validations, responsabilités).

Sécurité

• Décider du SSO et du modèle d’autorisations.
• Définir la journalisation (événements clés, conservation, accès).
• Prévoir sauvegardes et restauration, avec un scénario de test.

Exploitation

• Choisir le modèle d’hébergement et les environnements.
• Mettre en place monitoring et alerting.
• Définir un mode de support et des engagements de service.

Pilotage

• Fixer des jalons « preuves » (démo, intégration, parcours complet).
• Préparer la recette (scénarios, données de test, responsabilités).
• Planifier la réversibilité (exports, dictionnaire de données, dépendances).

En fin de cadrage, l’entreprise doit pouvoir répondre clairement à deux questions : qu’est-ce qui sera livré au MVP, et comment l’outil sera opéré et sécurisé une fois en production.