Cahier des charges logiciel supply chain : rubriques et oublis
Un cahier des charges logiciel supply chain doit rendre les offres comparables sans figer l'outil, en moins de trente pages. Les rubriques, les questions qu'on oublie et pourquoi 80 pages est un mauvais signe.
L'essentiel
Un cahier des charges logiciel supply chain doit rendre les offres comparables sans figer l'outil, en moins de trente pages. Les rubriques, les questions qu'on oublie et pourquoi 80 pages est un mauvais signe.
À quoi sert un cahier des charges, et à quoi il ne sert pas
Le cahier des charges d'un logiciel supply chain a une seule fonction utile : rendre les offres comparables et protéger la décision que vous prendrez, devant votre direction et devant vous-même dans deux ans. Il ne sert pas à décrire l'outil idéal, que personne ne vendra, ni à consigner toutes les envies de tous les services, qui se contredisent. Il a trois lecteurs aux attentes différentes, l'éditeur qui doit comprendre votre situation pour proposer juste, la DSI qui veut savoir ce que l'outil touchera dans le système d'information, et le DAF qui cherche le coût complet et les conditions de sortie. Un bon document répond aux trois en moins de trente pages, et il se rédige en quelques semaines, parce que le temps passé à écrire est du temps qui n'est pas passé à décider. Je le conçois comme une liste de vérification en prose plutôt qu'une spécification : chaque rubrique ci-dessous est un point à cocher, et l'ordre a son importance.
Les rubriques indispensables
Vérifiez d'abord que le contexte est décrit avec des ordres de grandeur : sites, familles de produits, nombre de références actives, volumes, saisonnalité, part d'export, tout ce qui permet à l'éditeur de dimensionner sans vous poser dix questions. Vérifiez ensuite que les processus cibles sont formulés en douleurs et en résultats attendus, une rupture récurrente sur telle famille, un S&OP mensuel qui n'arbitre rien, un stock de sécurité posé au doigt mouillé, plutôt qu'en fonctionnalités recopiées d'une plaquette. Vérifiez que les données disponibles sont inventoriées avec leur état réel, où elles vivent, à quelle fréquence elles sont mises à jour, ce qui manque, et que les intégrations attendues avec l'ERP, l'APS, le WMS et les tableurs sont nommées, avec le sens des flux. Vérifiez que les utilisateurs sont identifiés par rôle avec le temps qu'ils pourront consacrer au projet, que les contraintes non négociables sont listées, hébergement, sécurité, langue, validation réglementaire pour la pharma, et que le calendrier souhaité, le budget et le modèle de coût attendu sont écrits noir sur blanc. Vérifiez enfin que les critères d'évaluation sont pondérés avant de recevoir la première réponse, sinon la pondération s'adaptera à l'offre que vous préférez déjà.
La question qu'on oublie : que fait l'outil quand le plan casse
Presque tous les cahiers des charges décrivent le fonctionnement nominal, la prévision qui se calcule, le plan qui se génère, le tableau de bord qui s'affiche, et presque aucun ne décrit le mardi où un fournisseur annonce trois semaines de retard sur un composant critique. Vérifiez que votre document pose la question sans détour : dans cette situation, l'outil alerte-t-il, recalcule-t-il seul, chiffre-t-il les options possibles avec leur impact sur la marge, propose-t-il un arbitrage, et à qui ? Exigez que la démonstration se fasse sur un scénario cassé, avec vos données si possible, plutôt que sur le jeu de données propre que l'éditeur connaît par coeur. Une prévision tombe juste huit fois sur dix, et les deux fois où elle se trompe décident de votre marge ; un outil jugé sur son comportement les huit fois où tout va bien est un outil jugé sur ce qui ne coûte rien. Vérifiez aussi que le cahier demande comment l'outil conserve la trace des décisions prises face à l'imprévu, parce que la mémoire de ces arbitrages vaut souvent plus que le modèle qui les a précédés.
Les questions qu'on oublie : comment on le débranche, qui possède les données
Vérifiez que le cahier des charges traite la sortie avec autant de soin que l'entrée. Demandez dans quel format et sous quel délai vos données, vos paramétrages et l'historique de vos décisions vous seront restitués si vous arrêtez, ce que coûte cette restitution, et ce qu'il advient des modèles entraînés sur vos données une fois le contrat terminé. Demandez qui est propriétaire de quoi, des données brutes, des données enrichies, des règles que vos équipes auront construites dans l'outil, et si l'éditeur peut les utiliser pour améliorer son produit chez d'autres clients. Demandez ce qui se passe si l'éditeur est racheté, s'il abandonne le produit ou s'il change de modèle de prix, et faites inscrire une clause de réversibilité avec une période de transition. Ces questions paraissent défensives au moment de l'achat, elles deviennent centrales le jour où l'on veut changer, et ce jour arrive plus souvent qu'on ne le pense. Un éditeur qui répond avec précision à ces questions vous dit quelque chose de sa confiance dans son produit.
Le niveau de détail utile
Le bon niveau de détail décrit des situations et des résultats, jamais des écrans. Vérifiez que chaque besoin important est raconté comme un cas d'usage court, la situation de départ, ce que l'utilisateur doit obtenir, dans quel délai, avec quelle information en main, et laissez à l'éditeur le soin de proposer comment son outil y répond. Cette formulation a deux vertus : elle permet de comparer des outils conçus différemment, et elle laisse la place à une réponse que vous n'aviez pas imaginée. Vérifiez que les exigences sont classées en trois niveaux, obligatoire, souhaité et bonus, et que la liste des obligatoires tient sur une page ; si elle déborde, c'est qu'elle contient des souhaits déguisés. Vérifiez enfin que le document indique ce que vous ne voulez pas, un projet de migration de données, un remplacement de l'ERP, une refonte de vos processus avant la mise en service, parce que ces exclusions éliminent d'emblée les offres calibrées pour un autre segment que le vôtre.
Pourquoi un cahier de 80 pages est un mauvais signe
Je tiens un cahier des charges épais pour un symptôme plutôt qu'une preuve de sérieux. Quatre-vingts pages signifient le plus souvent que chaque service a ajouté sa liste sans que personne n'arbitre, que les fonctionnalités ont été recopiées des plaquettes des éditeurs consultés en amont, et que le document décrit l'outil que l'on connaît déjà plutôt que le besoin que l'on n'a pas encore résolu. Il enferme ensuite le projet dans un passé figé, puisque le besoin aura bougé avant la signature ; il fait fuir les éditeurs les plus agiles, qui refusent de répondre ligne à ligne à trois cents exigences, et il attire ceux dont le métier est de cocher des cases. Il coûte enfin des mois de rédaction et de relecture pendant lesquels les imprévus continuent de coûter ce qu'ils coûtaient la veille. Un document de vingt à trente pages, centré sur les situations à résoudre, l'état des données, les conditions de sortie et des critères pondérés, vous donnera des réponses plus comparables et une décision plus rapide. La longueur rassure celui qui écrit, elle n'a jamais protégé celui qui décide.
Cet article part d'une conviction : la prévision parfaite n'existe pas, ce qui compte c'est la décision d'après.
- À quoi sert un cahier des charges, et à quoi il ne sert pas
- Les rubriques indispensables
- La question qu'on oublie : que fait l'outil quand le plan casse
- Les questions qu'on oublie : comment on le débranche, qui possède les données
- Le niveau de détail utile
- Pourquoi un cahier de 80 pages est un mauvais signe
Clevizio
Clevizio est la couche de décision qui se branche sur vos outils existants : elle détecte l'imprévu, simule vos options et garde la mémoire de chaque arbitrage. Découvrir comment fonctionne le copilote de décision.
Mansour Niang
CEO & cofondateur de Clevizio
Une question sur vos imprévus ? Réservez 30 minutes avec moi pour estimer ce qu'ils vous coûtent vraiment, sans engagement.
Questions fréquentes
Que doit contenir un cahier des charges pour un logiciel supply chain ?
Le contexte chiffré, les processus cibles en douleurs et résultats, l'état des données, les intégrations, les utilisateurs, le budget et des critères pondérés. Ajoutez le calendrier et les contraintes non négociables. Deux rubriques manquent presque toujours : ce que fait l'outil quand le plan casse, et les conditions de sortie, réversibilité et propriété des données comprises.
Combien de pages doit faire un cahier des charges logiciel supply chain ?
Vingt à trente pages suffisent pour un outil de planification ou de décision. Au-delà, le document décrit en général des fonctionnalités recopiées plutôt que des besoins arbitrés, il allonge la consultation et il sélectionne les éditeurs qui cochent des cases plutôt que ceux qui résolvent le problème. Les besoins se décrivent en cas d'usage, pas en écrans.
Faut-il un cahier des charges pour un logiciel supply chain en SaaS ?
Oui, mais plus court et centré sur d'autres points. Le paramétrage est standard, le vrai sujet devient l'état de vos données, les intégrations avec l'existant, la sécurité et l'hébergement, la propriété des données et la réversibilité. Une dizaine de pages bien ciblées valent mieux qu'une grille fonctionnelle que l'éditeur cochera sans effort.
À lire aussi
Mettez enfin un chiffre sur ce que vos imprévus vous coûtent chaque année.
Commençons par estimer ce que vos imprévus vous coûtent réellement. C'est gratuit, ça prend 30 minutes, et vous repartez avec un chiffre que personne dans votre entreprise ne connaît aujourd'hui.