Lectures: 6
Résumé – Sans cadrage rigoureux, chaque développement risque d’être inadapté, générant dette fonctionnelle, déperdition d’adoption et surcoûts de refonte. En refusant vendor lock-in, offres low cost, projets précipités et promesses irréalistes, nous exigeons cadrage approfondi, architectures modulaires réversibles et gouvernance axée sur la valeur.
Solution : audit et ateliers de cadrage initiaux, contrats transparents et feuille de route de modernisation évolutive.
Un projet logiciel sur mesure mobilise bien plus que des compétences techniques : il façonne durablement l’organisation, les équipes et la trajectoire de l’entreprise. Adopter une posture claire sur ce que nous refusons de faire relève de notre responsabilité professionnelle.
En refusant certaines pratiques – livraisons sans cadrage, vendor lock-in, offres low cost, projets précipités ou promesses irréalistes – nous posons les bases d’une collaboration saine. Cette démarche garantit des solutions pertinentes, durables et alignées avec les objectifs métiers des acteurs suisses, quel que soit leur profil : DSI, CIO/CTO, COO ou direction générale.
Approfondissement des enjeux métiers
Nous refusons de livrer des logiciels sans compréhension approfondie des enjeux métiers. Nous considérons que chaque projet exige un cadrage sérieux et une remise en question du besoin.
Cadrage et alignement fonctionnel
Un projet bâti sans phase de cadrage détaillée se fonde souvent sur des hypothèses incomplètes ou dépassées. Cette absence de vision globale empêche d’anticiper les points de friction entre les processus existants et la future solution logicielle. Elle prive également les décideurs d’une cartographie claire des priorités, des risques et des jalons critiques.
Le cadrage n’est pas un simple exercice de documentation : il s’agit d’un moment d’échange entre les experts métiers, les responsables IT et les parties prenantes, destiné à identifier les contraintes opérationnelles et à formaliser les objectifs stratégiques. Cette étape doit s’appuyer sur des analyses de cas d’usage réels, des ateliers de travail et parfois des prototypes de validation.
En intégrant dès le début des retours réguliers des utilisateurs finaux, on évite les écarts majeurs entre le produit livré et les besoins réels. L’investissement consenti pendant le cadrage se traduit ensuite par des cycles de développement plus fluides, une adoption accrue et une réduction significative des ajustements post-déploiement.
Conséquences d’un déficit de compréhension
Lorsque les objectifs métiers ne sont pas clarifiés, le logiciel peut paraître techniquement conforme tout en demeurant inadapté aux usages quotidiens. Les équipes risquent de contourner l’outil, de maintenir des processus manuels parallèles ou d’ajouter des bricolages locaux pour compenser les lacunes perçues.
Cette situation génère une dette technique fonctionnelle : chaque personnalisation rapide devient un point de rupture lors des évolutions futures, gonflant les coûts de maintenance et complexifiant les mises à jour. À terme, l’outil survit plus par inertie que par valeur ajoutée effective.
Le manque d’adhésion des utilisateurs peut également induire un effet boomerang sur le sponsoring du projet, minant la confiance entre DSI, direction et prestataire. Une fois cette confiance entamée, il devient très difficile de la restaurer sans repartir sur de nouvelles phases d’audit et de refonte.
Exemple concret de cadrage insuffisant
Une PME suisse spécialisée dans la logistique a lancé un portail interne sans atelier de cadrage approfondi. Les équipes métiers ont découvert trop tard que certaines règles de stockage et de date-limite de livraison n’étaient pas prises en compte. Chaque manque donnait lieu à un travail manuel supplémentaire de plusieurs heures par semaine.
Au final, le logiciel, bien que techniquement abouti, a été mis de côté en attendant une refonte complète des règles métiers. Cet exemple montre que l’absence de temps dédié à la formalisation des besoins peut conduire à un double investissement : le développement initial et la reprise totale du projet quelques mois plus tard.
Il démontre aussi l’importance d’un cadrage valorisé en amont, reconnu dès la proposition commerciale comme une phase à part entière, indispensable à la réussite et à l’appropriation par les équipes.
Opposition au vendor lock-in
Nous refusons tout vendor lock-in, qu’il soit technologique, contractuel ou opérationnel. Nous privilégions des architectures ouvertes, documentées et réversibles, gages d’indépendance et de pérennité.
Les périls du vendor lock-in
Choisir une solution propriétaire sans plan de sortie expose l’entreprise à une dépendance forte vis-à-vis d’un éditeur ou d’un prestataire. Chaque mise à jour ou modification devient une renégociation tacite de tarifs et de conditions. Les délais de développement s’allongent et les coûts augmentent en raison de la complexité d’interfaçage avec d’autres systèmes.
Le vendor lock-in peut aussi entraver la capacité d’innover, car l’ajout de nouvelles briques nécessite souvent d’adopter l’écosystème de l’éditeur, même si elles ne répondent pas totalement au besoin. Il conduit alors à une inflation des licences et à un portefeuille d’applications hétéroclite, difficile à maintenir.
Architectures ouvertes et réversibles
Pour éviter ces écueils, il faut privilégier des solutions modulaires et normalisées. Une approche hybride mêlant briques open source et composants propriétaires bien isolés garantit un socle évolutif, tout en maîtrisant les coûts de licences.
La documentation complète des flux de données, des API et des formats d’échange est essentielle. Elle permet de limiter les ruptures technologiques et de faciliter le passage à un prestataire ou à une autre technologie si les besoins évoluent.
La réversibilité peut également s’appuyer sur des contrats clairs : clauses de portabilité des données, garanties de fourniture des codes source, ou encore clauses de split-billing pour les licences. Cette transparence contractuelle renforce la confiance et engage le prestataire à maintenir un accompagnement durable.
Exemple d’enfermement technologique
Un organisme de formation suisse avait misé sur une plateforme SaaS propriétaire pour gérer l’ensemble des inscriptions, la facturation et les évaluations. Après deux ans, les coûts de montée de version avaient triplé, et les adaptations aux nouveaux cursus devenaient prohibitifs.
La migration vers une solution open source orchestrée par un autre prestataire s’est avérée complexe car les données n’étaient pas exportables en masse. Il a fallu recréer manuellement plusieurs tables et réécrire les processus de facturation.
Ce cas illustre qu’un vendor lock-in non anticipé génère des surcoûts importants et fragilise l’agilité de l’organisation. Il montre aussi que la mise en place de standards ouverts et de formats interchangeables est un garant d’autonomie sur le long terme.
Edana : partenaire digital stratégique en Suisse
Nous accompagnons les entreprises et les organisations dans leur transformation digitale
Refus des offres centrées sur le prix
Nous refusons de vendre des projets uniquement sur un critère de prix ou de volume de jours-homme. Nous privilégions une logique de valeur, de gouvernance et de durabilité.
Les limites de l’approche au coût/jour
Une proposition fondée sur le taux journalier masque souvent la complexité réelle d’un projet. Elle crée une illusion de maîtrise budgétaire tout en générant une dette technique cachée dont la facture émerge après le démarrage.
Les équipes, sous pression pour maintenir le budget, peuvent être tentées de réduire la couverture de tests, de négliger la documentation ou de privilégier des briques standard mal adaptées. À terme, le logiciel devient coûteux à maintenir et difficile à faire évoluer.
Dans un contexte suisse où les processus soutenus par le logiciel sont souvent critiques, cette approche se retourne fréquemment contre l’entreprise, générant des coûts cachés et un rallongement des délais de déploiement pour chaque nouvelle version.
Gouvernance et vision long terme
Plutôt que de se focaliser sur le volume de jours-homme, il est préférable de clarifier les livrables attendus, les critères de succès et les jalons métiers. Cette gouvernance partagée permet de mesurer la valeur produite réellement à chaque étape.
La mise en place d’indicateurs – délai de mise en production, nombre d’incidents, taux d’adoption – rend plus transparente la performance du projet. Elle encourage également des arbitrages éclairés entre rapidité de livraison et qualité du code.
Une vision long terme inclut la planification des évolutions futures et l’identification des points de consolidation à prévoir. Cela limite la prolifération d’outils hétérogènes et maintient un socle cohérent et pérenne.
Exemple d’offre low cost inadaptée
Une entreprise helvétique du secteur financier a retenu l’offre la moins coûteuse pour refondre son module de reporting. Les développeurs pressés ont livré en mode “MVP” sans documentation ni tests de charge.
Deux mois après le go-live, la plateforme a saturé lors d’une période de clôture semestrielle, causant des retards de plusieurs jours et des pénalités réglementaires. La remise à niveau a coûté trois fois le budget initial.
Cette expérience démontre qu’un tarif attractif au départ peut entraîner des surcoûts et mettre en péril la conformité et la réputation de l’entreprise. Elle souligne l’importance d’une proposition fondée sur la valeur et le pilotage global du projet.
Intransigeance face aux projets mal cadrés et promesses irréalistes
Nous refusons les projets précipités basés sur des hypothèses floues et les discours enjolivés visant uniquement à obtenir une signature.
Prévenir les projets mal cadrés
Démarrer sans vision claire, c’est déplacer le risque plutôt que l’absorber. Les hypothèses non vérifiées peuvent conduire à des avenants en cascade, allongeant les délais et augmentant la complexité.
Pour limiter ces dérives, une phase d’audit et de priorisation est indispensable. Elle permet de confronter les besoins à la réalité des processus et d’identifier les fonctionnalités critiques qui justifient un investissement anticipé.
Cette étape, souvent perçue comme un coût inutile, est en réalité un investissement protecteur. Elle limite les surprises et aligne les attentes des métiers, des équipes IT et du prestataire sur un socle de vérité commun.
Intégrité du discours et promesses réalistes
Un projet logiciel comporte toujours des zones d’incertitude : délais de validation, complexité des intégrations, évolutions réglementaires ou métiers. Masquer ces zones nuit à la confiance mutuelle.
Un discours clair et transparent sur les risques, les arbitrages nécessaires et les marges de manœuvre favorise un partenariat durable. Il permet d’ajuster le scope en fonction des contraintes réelles et d’anticiper les points de blocage.
Affirmer dès le début ce que l’on ne pourra pas garantir – performances sous forte charge, délais fixes sans recul ou couverture exhaustive sans budget approprié – consolide la relation et évite l’effet “promesse non tenue”.
Rigorosité technique et esprit critique
Un prestataire agile ne signifie pas absence de rigueur. Les choix technologiques doivent être remis en question en fonction du contexte et du risque. Adopter une méthodologie sans réflexion critique peut mener à l’échec.
Nous considérons qu’un projet de transformation digitale requiert un dialogue permanent, des revues de code régulières et des points d’étape sincères. Tout écart entre le besoin et la réalisation doit être évoqué, documenté et priorisé.
Cette posture exigeante crée une dynamique de responsabilité partagée : chaque acteur est invité à challenger les décisions, dans l’intérêt de la qualité, de la sécurité et de la pérennité de la solution.
Exemple de projet rigide abandonné
Une administration cantonale avait validé une architecture monolithique et un planning serré sans compromis possible. Malgré les alertes techniques, le projet a démarré et accumulé les retards.
À mi-parcours, le DSI a décidé de stopper le chantier face à l’absence de marge de manœuvre et aux risques de sécurité identifiés. La reprise a nécessité un audit complet et une réorientation technologique sur une base modulaire.
Ce cas montre qu’accepter un projet sans capacité d’adaptation est plus dangereux que de suspendre immédiatement. L’arrêt opportun a évité des années de surcoûts et d’obsolescence prématurée.
Bâtir des projets logiciels solides et durables
Refuser certaines pratiques ne relève pas d’un principe de rigidité, mais d’une vision de responsabilité professionnelle. En exigeant une compréhension approfondie des enjeux métiers, en garantissant l’indépendance technologique, en valorisant la création de valeur plutôt que le seul coût, et en maintenant un discours transparent, on pose les fondations de projets pérennes.
Ces exigences sont les garantes de logiciels adoptés, évolutifs et sécurisés, qui accompagnent la croissance et l’agilité des organisations suisses. Nos experts restent à votre disposition pour étudier vos enjeux, challenger vos choix et vous accompagner sur la trajectoire digitale la plus adaptée.
