Logiciel sur mesure

Cadrage de projet informatique : ce qui doit être décidé avant de signer

Un devis à huit mille euros et un devis à vingt-quatre mille euros pour la même demande orale : c'est souvent le premier signe qu'un projet de logiciel sur mesure n'a pas été cadré. Un cadrage de projet informatique, c'est la décision de cinq choses avant qu'un développeur écrive une ligne de code : qui utilisera l'outil, quelles données il touche, quel périmètre entre dans le prix, comment on vérifiera que ça marche, et qui valide chaque choix côté entreprise. Cette page détaille ces cinq décisions, ce que ça coûte de les sauter, combien de temps et d'argent un cadrage sérieux demande, et comment reconnaître qu'il est terminé.

Ce qu'on entend par cadrage, et ce que ce n'est pas

Deux prestataires reçoivent la même demande orale : une application pour suivre les stocks, ouverte aux magasiniers et à la direction. Le premier devis tombe à huit mille euros, le second à vingt-quatre mille pour, en apparence, le même projet. L'écart ne vient presque jamais d'une marge différente entre les deux entreprises. Il vient de tout ce qui n'a pas été tranché avant de chiffrer : quelles données existent déjà, quel périmètre entre dans le prix, qui valide les choix une fois le développement commencé.

Un cadrage n'est pas un document. C'est la décision de cinq choses précises, détaillées dans la section suivante : qui utilise l'outil, quelles données il touche, quel périmètre est couvert, comment on juge que ça marche, et qui signe. Le cahier des charges est le document qui couche ces décisions par écrit, dans un format qu'un développeur peut lire sans revenir vous poser dix fois la même question. Le devis, lui, n'est que le prix qui découle de ce document une fois qu'il existe.

Ce que le cadrage n'est pas non plus : une présentation commerciale déguisée en méthode, un empilement de diapositives qui rassurent sans rien décider, ou une architecture technique réservée aux développeurs. Un bon cadrage se lit et se discute par quelqu'un qui n'a jamais ouvert un éditeur de code. S'il faut un ingénieur pour comprendre ce qui a été décidé, le document a raté sa cible : il devait servir de base à une décision d'entreprise, pas démontrer une compétence technique.

Le cadrage est une étape parmi d'autres dans la construction d'un logiciel sur mesure : il précède le développement, et il répond à une question différente de celle du choix entre construire ou adapter un outil du marché. Si cette question-là vous occupe encore, elle se traite ailleurs. Ici, on part du principe qu'un projet sur mesure est déjà décidé, et on s'occupe de ce qui doit être clair avant qu'il coûte un euro.

Le mot lui-même s'use vite dans la bouche des prestataires. Beaucoup de propositions commerciales parlent de « phase de cadrage » sans jamais dire ce qui en sort concrètement, un peu comme on parlerait d'une réunion de lancement. Cette confusion coûte cher : un dirigeant qui paie pour un cadrage doit repartir avec des décisions écrites, pas avec l'impression d'avoir bien discuté pendant deux heures.

Retenez cette distinction à trois niveaux, elle revient tout au long de cette page : le cadrage décide, le cahier des charges écrit, le devis chiffre. Confondre les trois, c'est payer pour l'un en croyant avoir acheté les deux autres, et découvrir l'écart au moment le plus coûteux du projet.

Les cinq décisions qui doivent sortir d'un cadrage

Cinq réponses suffisent à faire d'un cadrage un projet réel plutôt qu'une intention. Elles n'ont rien de sophistiqué : n'importe quel dirigeant peut les comprendre et les vérifier lui-même. Ce qui compte, c'est qu'elles soient écrites, datées, et signées par quelqu'un qui a l'autorité de les changer plus tard s'il le faut.

Première décision : qui utilisera l'outil, et pour faire quoi précisément. Pas « les commerciaux », mais « le commercial terrain saisit une visite en trente secondes depuis son téléphone, sans connexion, et la direction consulte un tableau chaque lundi ». Cette précision change tout : un outil pensé pour une saisie rapide sur le terrain ne ressemble pas à un outil pensé pour une consultation au bureau.

Deuxième décision : quelles données l'outil lit ou écrit, et où elles vivent aujourd'hui. Un exemple écrit ressemble à ceci : « les stocks sont dans un tableur partagé, mis à jour deux fois par jour par le magasinier, le nouvel outil le remplace et devient la seule source ». Sans cette phrase, personne ne sait si les données existent déjà ou s'il faut d'abord les collecter, ce qui change la durée du projet du simple au double.

Troisième décision : quel périmètre entre dans le prix, et surtout, quel périmètre en sort. Une phrase type : « le suivi des commandes fournisseurs n'est pas inclus dans cette première version, il pourra faire l'objet d'un développement séparé ». Cette phrase protège les deux parties : le client sait ce qu'il n'a pas acheté, le prestataire sait ce qu'il n'a pas à livrer sans le facturer.

Quatrième décision : comment on saura, le jour de la livraison, que l'outil fonctionne. Un critère écrit ressemble à : « un magasinier saisit une entrée de stock en moins de vingt secondes, et le total apparaît juste dans le tableau de la direction sans ressaisie ». Sans ce critère noté à l'avance, la réception se discute à l'oral, et chacun défend sa propre définition de « ça marche ».

Cinquième décision : qui, dans l'entreprise, a l'autorité de valider chaque choix. Sur un petit projet, une seule personne peut suffire. Sur un projet qui touche plusieurs services, il faut nommer, pour chaque zone, la personne dont l'accord ferme la question. Sans ce nom écrit, une décision validée par un service se voit renversée trois semaines plus tard par un autre qui découvre le sujet.

Ces cinq réponses tiennent sur une page. Elles ne remplacent pas un cahier des charges complet, mais elles en forment le squelette : tant qu'elles ne sont pas écrites, aucun chiffrage sérieux n'est possible, et tout ce qui suit se négocie à l'aveugle.

Ce que ça coûte de ne pas les avoir prises

Un exemple vu souvent : le projet démarre sur l'idée que les données clients sont propres dans un tableur. À la moitié du développement, il apparaît que la moitié des lignes portent des doublons, des adresses mal orthographiées, des colonnes utilisées pour trois usages différents selon la personne qui les a remplies. Le développeur doit s'arrêter, l'entreprise doit nettoyer, et un avenant tombe sur la table, souvent au moment le moins confortable du calendrier.

Autre scène fréquente : deux services de l'entreprise avaient chacun leur idée de « qui décide ». Le service commercial valide un écran, le service comptable le fait refaire trois semaines plus tard parce que personne ne lui avait demandé son avis. Personne ne gagne à cette situation : le prestataire recommence un travail déjà facturé, et le client paie deux fois pour le même écran.

Le coût réel ne se limite pas au montant de l'avenant. Il inclut le mois de retard que personne n'avait budgété, et la confiance qui s'effrite entre le client et le prestataire à chaque surprise. Un projet qui accumule deux ou trois avenants finit rarement bien, même quand chaque avenant pris isolément semble raisonnable.

Ce n'est presque jamais une question de compétence du développeur. Un bon développeur code ce qu'on lui décrit, il ne devine pas les règles métier que personne n'a écrites, ni les données qui n'existent en réalité que dans la tête d'un employé parti en congés au mauvais moment. Le cadrage sert justement à faire remonter ces éléments avant qu'ils ne coûtent une ligne de code.

Sauter cette étape donne l'illusion de gagner du temps au départ, puisque le développement démarre plus tôt. Le temps gagné au premier mois se paie en général avec des intérêts au troisième ou au quatrième, sous forme de reprises, d'écrans refaits, de fonctions qui ne servent à personne parce qu'elles répondaient à une hypothèse fausse.

Une entreprise qui vit ce scénario une fois en tire en général la leçon pour le projet suivant. Le problème, c'est que la leçon coûte souvent le prix d'un cadrage complet, payé en avenants successifs plutôt qu'en une seule fois avant que le développement ne commence.

Une objection revient souvent : « on connaissait déjà ces données, pourquoi payer pour les revalider ? » La réponse tient en une phrase : connaître une donnée dans sa tête et l'avoir décrite noir sur blanc pour un développeur qui découvre votre entreprise ne sont pas la même chose. Le cadrage ne réapprend rien à votre équipe, il traduit ce qu'elle sait déjà dans un langage qu'un prestataire externe peut exploiter sans se tromper.

Qui doit être dans la pièce pendant le cadrage

Trois profils doivent participer, même si l'entreprise ne compte que quarante personnes. La personne qui utilisera l'outil au quotidien, celle qui décide du budget, et celle qui connaît vraiment les données existantes, qui n'est pas toujours la même que les deux premières.

L'utilisateur terrain apporte ce que personne d'autre ne sait : comment le travail se fait vraiment, avec ses détours et ses exceptions, pas comment il est censé se faire sur le papier. Un cadrage mené sans lui produit un outil qui respecte la théorie du poste et ignore sa pratique, ce qui se voit dès la première semaine d'utilisation.

Le décideur du budget doit être présent au moins aux moments d'arbitrage, sinon un choix validé en atelier revient en question trois semaines plus tard, quand il découvre le sujet pour la première fois en lisant le devis final. Sa présence n'a pas besoin d'être permanente, mais elle doit être garantie sur les points qui engagent de l'argent.

La personne qui connaît les données existantes évite le scénario du tableur découvert cassé à mi-projet. Dans beaucoup de PME, cette personne n'est ni le dirigeant ni l'utilisateur final, mais quelqu'un du service comptable ou administratif qui manipule ces fichiers depuis des années sans que personne d'autre ne s'en soucie.

Dans une petite structure, ces trois profils peuvent se réduire à deux personnes, voire une seule qui cumule les rôles. Ce n'est pas un problème en soi, tant que cette personne prend le temps de se mettre, consciemment, dans chacune des trois postures pendant les ateliers, plutôt que de répondre uniquement depuis son fauteuil de dirigeant.

Un exemple parlant : un cadrage mené uniquement avec la direction, sans personne du terrain, produit régulièrement un outil techniquement correct que les équipes n'utilisent pas. Elles continuent leur tableur habituel en parallèle, parce que l'outil ne colle pas à leurs habitudes réelles, et l'investissement dort sur un serveur.

L'absence d'un seul de ces trois profils ne se voit pas immédiatement. Elle resurgit en général trois ou quatre semaines plus tard, sous la forme d'une question qu'on croyait tranchée et qui revient parce que la bonne personne n'était simplement pas dans la pièce au bon moment.

Combien de temps ça prend, et ce qui fait varier la durée

Sur les cadrages que nous menons, un projet ciblé, quand vous savez déjà quoi construire, prend une à deux semaines, et un tour d'horizon complet de l'entreprise, quand vous cherchez encore le bon projet à lancer, en prend deux. Ces ordres de grandeur restent indicatifs : un cadrage mené par un autre prestataire, ou en interne, peut suivre un rythme différent selon la taille de l'entreprise.

Côté client, l'effort réel se mesure en demi-journées plutôt qu'en semaines : comptez trois à cinq demi-journées réparties sur la durée, pour les personnes qui connaissent le terrain. Le reste du travail, l'écriture, les maquettes, le chiffrage, se fait chez le prestataire, sans mobiliser davantage l'entreprise.

Ce qui rallonge un cadrage, en premier lieu : des données dispersées dans plusieurs outils qui ne se parlent pas. Un tableur ici, un logiciel de facturation là, des notes personnelles ailleurs. Chaque source supplémentaire ajoute une vérification, et une vérification bâclée coûte bien plus cher plus tard qu'une semaine de plus au cadrage.

Deuxième facteur qui rallonge : une décision qui doit remonter à un comité qui ne se réunit qu'une fois par mois. Un cadrage bien mené peut trancher la plupart des questions en atelier, mais certains arbitrages, en général ceux qui touchent plusieurs services, exigent un aller-retour que le calendrier de l'entreprise impose, pas le prestataire.

Aucun de ces deux facteurs n'est un défaut de méthode : ils reflètent simplement la réalité d'une entreprise qui continue de tourner pendant qu'on la cadre. Un bon prestataire prévient de ce risque au devis plutôt que de promettre un délai qu'il ne tiendra pas.

Une règle simple pour vous situer : si vous répondez sans hésiter aux cinq décisions de la deuxième section, le cadrage ira vers le bas de la fourchette. Si chaque question ouvre un débat interne que personne n'avait eu avant, comptez plutôt sur le haut, et prévoyez-le au devis.

Ce que ça coûte, et ce qui doit être écrit dans le prix

Chez Techmind, un cadrage de projet ciblé coûte 3 900 euros hors taxes, et un tour d'horizon complet de l'entreprise coûte 5 000 euros hors taxes, montants identiques en francs suisses pour les clients romands, taxe locale en sus. Ces chiffres varient d'un prestataire à l'autre, mais donnent un ordre de grandeur raisonnable pour ce travail en France et en Suisse romande.

Le montant compte moins que ce qu'il doit couvrir noir sur blanc : les entretiens avec les personnes qui utiliseront l'outil, une carte de ce que les données existantes permettent et ne permettent pas, et un document final qui sert de base ferme au chiffrage du développement. Un devis de cadrage qui ne nomme pas ces trois éléments laisse une zone grise sur ce que vous achetez réellement.

Un détail mérite d'être écrit au devis, et pas seulement promis à l'oral : si le développement démarre chez le même prestataire dans les semaines qui suivent, le montant du cadrage se déduit en général du forfait de construction. Ce n'est donc pas une dépense perdue si le projet se poursuit, à condition que cette déduction soit posée noir sur blanc avant de signer.

Le détail complet, les deux formats et ce qu'ils couvrent précisément, vit sur la page de l'offre Cadrage. Ce qui mérite d'être répété ici : un cadrage sérieux vous laisse le droit de renoncer. S'il montre que le gain ne justifie pas la construction, vous vous arrêtez là, et vous aurez dépensé le prix d'un cadrage plutôt que celui d'un projet entier mené à contrecœur.

Pour situer ce montant : un premier outil sur mesure coûte en général entre 15 000 et 50 000 euros à construire. Un cadrage à 3 900 ou 5 000 euros représente donc une fraction du budget total, payée avant d'engager le reste, pour vérifier que ce reste sera bien dépensé.

Méfiez-vous d'un cadrage annoncé à un prix symbolique, presque pour rien : il sert alors souvent d'accroche commerciale plutôt que de travail réel, et le document qui en sort ne tient pas la route face à un vrai chiffrage. Un cadrage qui vaut la peine d'être payé prend du temps aux deux parties, et ce temps se voit dans le prix.

Comment savoir qu'un cadrage est fini

Le critère est simple à énoncer, plus difficile à respecter : un cadrage est terminé quand les cinq décisions de la deuxième section sont écrites, relues et signées par la personne qui a l'autorité de les valider côté client. Pas quand le prestataire sent que le projet est clair dans sa tête.

Cette différence compte, parce qu'un prestataire pressé de démarrer le développement a intérêt à déclarer le cadrage fini un peu tôt. Le signal fiable n'est jamais une impression, c'est un document que le client a lu en entier et dans lequel il reconnaît sa propre demande, mot pour mot.

À l'inverse, certains cadrages traînent parce que personne n'ose dire qu'ils sont terminés, par peur d'avoir oublié un cas particulier. Ce risque existe, mais il se traite autrement : en écrivant explicitement ce qui reste en dehors du périmètre plutôt qu'en repoussant indéfiniment la signature en espérant couvrir tous les cas possibles.

La signature elle-même doit venir de quelqu'un qui a le pouvoir de faire changer un choix plus tard, pas d'un intermédiaire qui relaiera la question à son tour. Sur un petit projet, ce sera le dirigeant lui-même. Sur un projet qui touche plusieurs services, ce sera la personne désignée dans chaque zone du document pour cette décision précise.

Une fois ces documents signés, le chiffrage de la construction devient ferme au lieu de rester indicatif. Ce basculement, dans la pratique, marque la fin réelle d'un cadrage, bien plus que n'importe quelle date posée sur un planning.

Un moyen simple de tester si un cadrage est vraiment fini : demandez à deux personnes de l'entreprise qui l'ont lu de décrire, chacune de son côté, ce que l'outil fera le premier jour d'utilisation. Si leurs réponses divergent, le document n'est pas terminé, même s'il est déjà signé.

Ce qui coince le plus souvent en pratique

Trois blocages reviennent sur la plupart des cadrages que nous menons, et aucun des trois n'a de solution miracle : ils se traitent, ils ne se contournent pas.

Premier blocage : des données existantes qu'aucun document ne décrit. Le cadrage se transforme alors en enquête, où il faut retrouver qui sait quoi, dans quel fichier, avec quelle fiabilité. Ce travail d'enquête a un coût réel, et il vaut mieux le nommer dès le devis plutôt que de le découvrir en cours de route.

Deuxième blocage : une entreprise qui n'a jamais tranché entre deux façons de faire en interne. Le service A calcule une remise d'une manière, le service B d'une autre, et personne n'a jamais eu à choisir puisque chacun travaillait dans son coin. Le cadrage impose alors un choix que le prestataire ne peut pas prendre à la place de l'entreprise : il ne fait que révéler que la question existait déjà, sans réponse.

Troisième blocage : un décideur trop occupé pour valider dans les temps. Les questions s'accumulent en attente de sa réponse, et le calendrier glisse sans que personne ne le veuille vraiment. La parade la plus efficace reste de fixer, dès le devis, des créneaux de validation nommés, plutôt que de compter sur la bonne volonté du moment.

Ces blocages apparaissent souvent quand le projet part d'un outil déjà en place qu'on cherche à remplacer : les données existent, mais dans un format que seul l'ancien outil comprend, et personne ne s'était jamais posé la question de leur qualité tant qu'il tournait encore. Si votre projet ressemble à ça, la page sur la refonte d'un logiciel existant détaille les signes qui indiquent qu'il est temps de remplacer un outil plutôt que de le rafistoler.

Aucun de ces trois blocages ne remet en cause l'intérêt du cadrage. Ils montrent plutôt pourquoi il vaut la peine d'être fait avant de signer un forfait de développement : mieux vaut découvrir une question sans réponse pendant un atelier de deux heures que pendant un sprint déjà facturé.

Cadrage fait en interne ou avec un prestataire

Un dirigeant qui connaît bien son propre métier peut écrire lui-même une bonne partie d'un cadrage. S'il sait nommer les utilisateurs, décrire les données, et poser un périmètre clair, rien n'oblige à payer un prestataire pour ce travail : un document imparfait mais honnête vaut mieux qu'un document soigné qui attend dans un coin.

Ce qu'un regard extérieur apporte, en revanche, c'est la capacité à repérer les trous et les questions non posées. Un prestataire qui a mené des dizaines de cadrages reconnaît les hypothèses fragiles avant qu'elles ne deviennent des avenants, simplement parce qu'il les a déjà vues échouer ailleurs.

Le cadrage en interne suffit en général pour un petit projet : un seul service concerné, une seule personne qui décide, des données déjà propres et bien identifiées. Dans ce cas, un document d'une ou deux pages, écrit avec soin, peut remplacer une prestation entière.

Le recours à un prestataire devient utile quand plusieurs services sont concernés, quand les données sont dispersées ou douteuses, ou quand personne en interne n'a l'habitude d'écrire ce genre de document sans en oublier la moitié. Ce n'est pas une question de taille d'entreprise, mais de complexité réelle du projet.

Un exemple concret aide à trancher : un dirigeant qui rédige seul un cadrage oublie presque toujours de préciser ce qui reste hors périmètre, parce que cette question ne le préoccupe pas au moment où il écrit. Un regard extérieur habitué à négocier des devis comble souvent ce point-là, pas grâce à une compétence technique supérieure, mais parce qu'il a déjà vu ce trou ailleurs.

Il serait malhonnête de prétendre qu'un cadrage payant est toujours nécessaire. Un tout petit projet, une simple automatisation d'une tâche répétitive avec une seule donnée en entrée, peut parfaitement se passer de cette étape formelle. La question à se poser reste la même : si ce projet échoue faute d'avoir bien posé les bases, combien coûte de reprendre à zéro ?

Ce qui se passe une fois le cadrage terminé

Un cadrage terminé ne clôt pas le sujet, il ouvre la phase suivante : le document signé sert de base au devis de développement, sprint par sprint, sans que le prix rebouge une fois le premier jour de construction passé.

Il arrive souvent qu'un cadrage débouche sur un périmètre volontairement réduit pour la première version : plutôt que de construire les dix fonctions imaginées au départ, l'entreprise choisit d'en livrer trois qui couvrent déjà l'essentiel du gain attendu, et de juger sur pièces avant d'aller plus loin.

Cette logique porte un nom, et elle mérite sa propre page : le guide sur le MVP détaille comment réduire un périmètre sans perdre l'essentiel du projet, une question qui se pose à la sortie d'un bon cadrage.

Un cadrage peut aussi déboucher sur un report ou un renoncement, et ce n'est pas un échec du travail fait. Si le document révèle que le gain attendu ne couvre pas le coût de construction, mieux vaut le savoir pour trois mille ou cinq mille euros que pour le prix d'un projet entier mené jusqu'au bout par habitude.

Rien n'oblige non plus à confier la construction au prestataire qui a mené le cadrage. Un document bien écrit se met en concurrence entre plusieurs prestataires, ou se confie à une équipe interne si l'entreprise en a une. Un cadrage qui ne fonctionnerait qu'avec son auteur ne mériterait pas ce nom.

Ce qu'on construit avec vous chez Techmind

Chez Techmind, un cadrage se construit à partir d'entretiens avec les personnes qui utiliseront réellement l'outil, pas seulement avec la direction. Nous écoutons comment le travail se fait aujourd'hui, avec ses détours et ses habitudes non écrites, avant de proposer quoi que ce soit.

Nous dressons ensuite une carte des données existantes : ce qui est déjà propre et exploitable, ce qui demande un nettoyage, ce qui n'existe simplement pas encore et devra être créé. Cette carte évite la découverte à mi-projet d'un tableur qu'on croyait fiable et qui ne l'était pas.

Le document final réunit les cinq décisions, un chiffrage ferme de la construction sprint par sprint, et pour le format projet ciblé, des maquettes des écrans principaux. Vous repartez avec de quoi lancer, reporter ou renoncer en connaissance de cause, sans jargon de gestion de projet à décoder.

Le prix, le contenu exact des deux formats et ce qui est inclus se lisent en détail sur la page de l'offre Cadrage. Le document reste à vous, quelle que soit la suite que vous lui donnez.

Cette étape s'inscrit dans un parcours plus large, celui de la construction d'un logiciel sur mesure, du premier doute jusqu'à l'outil qui tourne en production. Si vous cherchez encore à savoir quoi construire avant même de penser au cadrage, ce guide pose les repères, prix compris.

Si vous avez déjà deux devis qui ne se ressemblent pas pour le même projet, ou si vous hésitez encore sur ce qu'un cadrage doit couvrir chez vous, décrivez-nous votre situation. Nous vous dirons quel format correspond, et ce que ça change concrètement pour votre projet.

Questions fréquentes

C'est quoi un cadrage de projet informatique ?

C'est la décision, avant tout développement, de cinq choses : qui utilisera l'outil, quelles données il touche, quel périmètre entre dans le prix, comment on jugera que ça marche, et qui valide ces choix côté entreprise. Une fois écrites, ces décisions servent de base à un chiffrage ferme du développement.

Combien coûte un cadrage de projet informatique ?

Chez Techmind, un cadrage de projet ciblé coûte 3 900 euros hors taxes, et un tour d'horizon complet de l'entreprise coûte 5 000 euros hors taxes. Si la construction démarre chez le même prestataire dans les semaines qui suivent, ce montant se déduit en général du forfait de développement.

Combien de temps dure un cadrage de projet ?

Comptez une à deux semaines pour un projet déjà identifié, deux semaines pour un tour d'horizon complet de l'entreprise. Côté client, l'effort réel tient en trois à cinq demi-journées réparties sur cette durée, le reste du travail se faisant chez le prestataire.

Cadrage et cahier des charges, c'est la même chose ?

Non. Le cadrage est la décision, le <a href="/logiciel-sur-mesure/cahier-des-charges/">cahier des charges</a> est le document qui la couche par écrit. On peut avoir pris les bonnes décisions sans les avoir encore mises en forme dans un document exploitable par un développeur, et inversement un document soigné peut cacher des décisions jamais vraiment tranchées.

Qui doit participer au cadrage d'un projet informatique en PME ?

Trois profils, au minimum : la personne qui utilisera l'outil au quotidien, celle qui décide du budget, et celle qui connaît réellement les données existantes. L'absence d'un seul de ces trois profils resurgit en général quelques semaines plus tard, sous la forme d'une question qu'on croyait tranchée.

Comment savoir qu'un cadrage est terminé ?

Quand les cinq décisions sont écrites, relues et signées par la personne qui a l'autorité de les valider côté client, pas quand le prestataire estime que le projet est clair dans sa tête. Une fois ces documents signés, le chiffrage de la construction devient ferme.

Peut-on se passer d'un cadrage pour un petit projet ?

Oui, dans certains cas : un projet limité à un seul service, une seule personne qui décide, des données déjà propres. Un document d'une ou deux pages écrit avec soin par l'entreprise elle-même peut alors suffire. La prudence s'impose surtout quand plusieurs services sont concernés ou que les données sont dispersées.

On continue la lecture ?

  1. Logiciel sur mesure : le guide pour décider si c'est votre cas
  2. La tierce maintenance applicative, expliquée à un dirigeant qui n'a pas de DSI
  3. Maintenance de site internet : ce qu'un contrat couvre vraiment
  4. Le sprint agile vu du bureau du dirigeant qui paie
  5. Cadrage de projet informatique : ce qui doit être décidé avant de signer
  6. MVP : ce qu'on met dedans, ce qu'on laisse dehors
  7. Application métier : l'outil qui épouse votre façon de travailler
  8. Remplacer Excel : les signes que le tableur ne suffit plus
  9. La dette technique, expliquée à un dirigeant qui ne code pas
  10. Refonte d'un logiciel : réécrire, moderniser, ou remplacer ?
  11. Le cahier des charges d'un logiciel, sans jargon et sans 40 pages

Nos guides

  1. Audit informatique en PME : le guide
  2. Assistant IA : le guide complet
  3. Faire analyser mon site
  4. Voir comment se passe un audit stratégique

On en parle ?

Nous écrire Prendre rendez-vous