En fait vous n’etes pas du tout sur les memes style de projets !
@tibastral, imagine toi qu’en face t’as du marketing ou de la com pour qui le desgin soit l’élément le plus important : il fait d’abord bosser son agence de Com’ sur les créa et un story, il passe au moins 2 mois à faire des aller/retours.
Au final ta partie de dev ne l’intéresse pas vraiment, il ne la connait pas c’est trop abstrait pour lui.
Donc avec ce type d’interlocuteurs, ta démarche est très compliquée.
Par contre pour des plus petits projets, ou pour des pme/tpe cela correspond exactement à leur besoin : une maitrise des couts vs le résultat obtenu. Et j’aime beaucoup ton approche qui donne une très dans valeur perçue à ta prestation !
Suivant les typologie d’intervenants, de clients, de projet, d’importance du projet pour le client, … l’approche et le type de presta attendu n’est pas le meme.
Je suis globalement d’accord avec ce que tu écris (j’ai intégré l’agilité par Scrum il y a 7 ou 8 ans, elle fait donc partie de la panoplie) même si je ne partage pas ta vision du monde de la PME.
Mais surtout, je me rends compte que je ne suis pas sur un forum d’entrepreneurs mais sur un forum d’entrepreneurs du web avec une vision focalisée sur le web et connexe.
Les systèmes d’information vont bien au delà du web et concerne tout type d’entreprise.
Mais surtout, les SI ne sont pas le cœur de métier des clients avec lesquels je travaille.
Je crois qu’on ne parle pas du même métier et que je me suis tout simplement trompé de forum (ça arrive).
D’ou le quiproquo (je pensais que le débat serait moins fermé sur la méthode et plus ouverts sur la vision du client).
comment tu définis le « web » dans ton dialogue, avec de plus en plus de SaaS et autre cloud …
Maintenant, je vois rarement des « gros projets » où on ne parle pas d’intégration avec CRM/ERP et autre outils « internes » (qui peuvent aussi bien être en SaaS, donc pas si internes que ça)
Tu saurais nous dire pourquoi ? Choix de ta part ?
Je suis preneur aussi d’un exemple de projet de dev, qui ne touche pas aux techno web/mobile (j’ai des idée en tête, genre informatique embarquée par exemple)
Du coup, quels sont tes interlocuteurs ?
Je ne sais pas si le forum est peuplé d’entrepreneurs web, mais ce sont ceux qui participent le plus sur ce genre de sujet, ça oui. Et les dev sont surtout dev web/mobile, c’est fortement possible.
L’industrie et le retailing sont très présents dans ma région… donc par opportunité au départ puis j’ai continué en raison du nombre de métiers rencontrés.
Pour le dev:
ERP: partir d’un open source et redévelopper en fonction des besoins
Logiciel métier: si pas de solution satisfaisante sur le marché: dev from scratch
EDI: la société dispose de très bons logiciels métiers et ne souhaite pas migrer vers un ERP, l’EDI permet de rajouter une couche simulant les avantages de l’ERP, c’est à dire workflow, db commune, etc.
Datawarehouse, Datamining, BI pour le marketing généralement
Tout ce qui touche au Supply Chain management et à la gestion de prod (MRP,Lean, etc.)
Et les services finances pour tout ce qui touche au dashboard et BI
Voilà pour le type de projets qui me viennent en tête.
L’avantage c’est que ça demande une très bonnes connaissances du métier de ton interlocuteur ce qui t’oblige à apprendre (intégrer vite des notions assez poussées), passer beaucoup de temps avec lui, etc.
Pour ma part je trouve ça très enrichissant et permet de travailler avec des personnes de tous horizons.
Par ex. la Supply Chain et la gestion de prod sont les domaines ou les méthodologies sont les plus poussées et les mieux maitrisées… on apprend énormément sur ce type de presta.
Lors des interventions?
Toutes parties prenantes directement concernées (ça peut être un ordonnanceur, une secrétaire, une personne à la prod, aussi bien qu’un directeur ou le DG).
Sinon il y a toujours un coPIL (comité pilotage) avec la DG ou le comDIR (comité direction)… donc pas mal de temps avec eux suivant l’importance du projet
Une contractualisation Agile, est un forfait par période de x jours (un sprint, en réalité, soit généralement une période de 1 à 2 semaines). Au sein de cette période, il est impossible de changer la demande. Le changement d’avis (du client, car on s’adapte au feedback renvoyer par le dev de l’application) est possible inter-sprint.
Tous les x jours, à la fin de chaque sprint, chaque partie (client et prestataire) sont libres de partir ou de continuer ensemble. Le fait que chacun ne s’engage pas plus de x jours, permet une relation basée sur la confiance, car « on ne peut arnaquer son vis ) vis que de x jours ».
Cela permet de sortir de l’éternel problème du « scope » changeant d’un cahier des charges.
De fait, ce mode de fonctionnement n’est pas une solution universelle, il dépend grandement de la capacité du prestataire ET (surtout) du client à envisager un mode de partenariat basé sur la Confiance, le Feedback et l’amélioration continue.
Pour répondre à certaine de tes affirmations. Croire que le client n’est pas con car il choisit un contrat au forfait est ne pas comprendre que tout écosystème s’adapte aux contraintes qu’on lui fournit. Une boite de prestation existe car elle a un minimum de rentabilité, et croire qu’on peut réellement faire porter tout le risque sur elle est très hasardeux. J’ai vu ou entendu parler de quantité de contrat au forfait, ou le directeur des achats du client était super content car les budgets étaient respectés mais où les utilisateurs de l’appli codée étaient désolé car elle ne répondait pas du tout ses besoins.
Comme je le dis, tout le monde, et tous les clients ne sont pas prêt à travailler pour leur réussite immédiate et préfère envisager une relation sous le prisme de la domination (illusoire).
J’ai été très longtemps prestataire a qui on a envoyé des cahiers de charges écrit par des gens qui ne savaient/pouvaient se projeter. Le risque était donc pour moi et je me suis brûlé une ou deux fois. Ensuite on trouve des parades pour se protéger et ce n’est pas toujours à l’avantage du client.
Karim a raison dans sa description de la vie des PME/Gds groupes sur la gestion des budgets etc… Le DSI ne doit pas se planter. Mais sans doute un jour comprendra t’il que pour minimiser le risque qu’il prend en CoDIR, l’agilité peut être une solution. Il ne peut se planter que sur un sprint, pas sur un dev de 300j/H (je schématise).
Parce que le DSI n’est aussi qu’un prestataire du CoDIR. Avec les mêmes exigences que peut avoir un presta classique auprès de son client.
Je suis d’accord avec Ugo, l’agilité n’est pas vraiment de la régie. Pour moi c’est une expression de besoin importante sub-divisée en x mini forfaits (les sprints) avec des itérations inter-sprints pour revoir la demande.
Et je suis quasi certain que si Karim le voyait sous cet angle plutôt que de la régie pure il pourrait y trouver un intérêt et pas seulement pour les chantiers web
Ce n’est sans doute pas la panacée, c’est très exigeant pour le client, ça demande beaucoup de rigueur, mais une fois qu’on y a goûté on ne repasse plus au gros forfait type BTP. Parce ce que l’analogie entre un pont et une application malheureusement a fait beaucoup plus de mal à l’industrie du logiciel qu’autre chose (allez changer un des piliers du Pont de Millau pour comprendre)
Ce débat mériterait que l’on se retrouve physiquement pour continuer. Je ne sais pas pourquoi il me passionne autant.
PS : Mais l’agilité peut aussi recouvrir la notion de régie (sprint permanents) -> c’est plutôt mon utilisation actuellement concernant le Saas que j’édite.
Pourquoi parler de risque… il n’y en a aucun au forfait !
Un contrat de prestation au forfait est un contrat entre un contractuel (prestataire) qui a une obligation de résultat vis à vis du contractant (client).
Si le contractuel n’atteint pas les résultats attendus par le contractant tel que défini dans le contrat, le contractant n’a pas à payer le contractuel.
Si, en cas d’impératif time to market, le prestataire ne respecte pas ses engagements de délais, des pénalités seront ajoutées, au préalable, dans le contrat pour palier aux pertes du client.
Telle est la loi.
Il n’y a donc aucun risque pour le contractant, si bien sure il sait ficeler un contrat (sur les contrats important, on passe toujours par un juriste).
Donc je comprends toujours pas pourquoi on parle de risque pour le client… il n’y en a aucun si il ficèle bien son contrat.
Je comprends qu’en tant que prestataire vous ayez du mal à l’accepter mais voyez les choses du point de vue du CLIENT
Pourquoi prendrait il un contrat moins avantageux pour lui?
Car la régie, ou appelé le comme vous voulez, ne donne au prestataire qu’une obligation de moyen… et non de résultat.
Ca me semblait pourtant clair… mais ça n’a pas l’air.
« Il n’y a aucun risque pour le contractant » Je pense que c’est là où vous faites fausse route.
Vous auriez raison si en informatique il n’y avait qu’une façon et une seule de faire les choses, que cette chose soit aisément vérifiable en un temps raisonnable et que l’on puisse ainsi facilement et sans discussion statuer sur la qualité de cette chose (Validé/pas Validé)
Mais on a tort de penser que l’informatique est binaire. C’est plus souvent gris que noir ou blanc. Et cette zone de gris, de mon expérience, porte plus souvent tort au client qui, par définition, n’est pas forcément expert dans le domaine)
Si un webservice, par exemple, doit être écrit dans un cahier des charges à la ligne près pour éviter toute zone « grise » alors autant le coder directement
Pour être parfaitement honnête lorsque j’ai été sorti de ma zone de confort « au forfait » vers une démarche agile j’ai été très réticent. Mais avec des vrais pros, en confiance, en rigueur et engagement c’est bénéfique pour toutes les parties prenantes. Et ce n’est pas forcément de la régie !
Sauf que à moins de payer 100% à la livraison le procès est rarement rentable et faire exécuter un contrat, même bien ficelé par un avocat, est très difficile.
Tout simplement parce que le droit reste un code comme un autre, et qu’il n’est interprété qu’en procès, et comme on n’écrit pas encore de contrats en coq…
Salut Matthieu, (tu peux me tutoyer… on est sur un forum)
La différence de point de vue vient du fait que tu es sur du développement d’innovation ou sur des entreprises type start-up sans visibilité à moyen - long terme.
Et moi je suis sur du développement pour opérationnel dans des sociétés bien établies.
Je vais te donner un exemple de demande que je peux rencontrer pour illustrer mon point de vue.
(il est possible de chipoter parce que je n’ai pas trop détailler le truc, afin d’alléger l’ex, essayons de ne pas pinailler sur des vides laissés… pour un cdc de ce type je passerai plus de 3 min)
Une PME vend des fenêtres et portes sur mesure.
Elle dispose d’une force de vente répartie au niveau régionale, les commerciaux ne viennent au siège qu’une ou deux fois par mois.
Jusqu’à présent, les bons de commandes sont faxées tous les soirs, une personne les récupère tous les matins pour transmettre une copie à la compta, à la prod et à la direction commerciale pour les stats.
Pour l’instant tout est fait sur des tableaux Excel… c’est peu efficace et mobilise trop de monde sur des tâches à non valeur ajoutée avec risque d’erreurs (beaucoup de re-saisies).
La demande :
Les commerciaux devront remplir les bons sur un modèle depuis leur portable
Ils doivent pouvoir imprimer chez le client pour signature
Le soir, ils doivent connecter leur portable au siège pour transférer les bons de commandes
Automatiquement, les bons doivent être transmis à la prod avec la nomenclature détaillée et les dimensions.
Automatiquement, les bons doivent être transmis à la compta pour éditer et envoyer les factures aux clients.
Automatiquement, les bons doivent être transmis à la direction commerciale pour les stats : combien de ventes par jour, combien de ventes par commerciaux, ventes moyenne et stats géolocalisés via un SIG (pour avoir une vue sur les secteurs les plus rentables et les secteurs oubliés)
On veut un logiciel qui réponde à cette demande.
La demande est on ne peut plus claire (comme je l’expliquais, j’ai fait vite pour l’ex., on pourrait verrouiller certaines parties).
On peut vérifier aisément si le logiciel fonctionnera ou pas en préparant une série de tests unitaires et globaux. On imposera une recette sur plusieurs semaines, on préparera des milliers de bons factices pour vérifier la charges, etc. etc.
Le besoin est clairement identifié, il est stable et on connaît exactement le résultat souhaité.
Pas de zone grise: on veut un truc qui fasse papa/maman et pas un lanceur pour Saturne.
Pourquoi partir sur de l’agile alors que nombre de prestataires ont déjà réalisé ce genre d’outils et sont donc en mesure de répondre à la demande sur cahier des charges (comme on peut le voir il n’est que fonctionnel… c’est entièrement suffisant).
Maintenant j’ai aussi bossé sur des demandes à innovation très fortes où là l’agilité s’imposait à un moment donné dans le projet parce qu’on ne savait pas ou on mettait les pied.
Et là on faisait appel à de la régie (j’utilise les termes contractuelles)
Mais ce genre de demandes est souvent faite par de grands groupes (ou start-up), rarement par les PME: en règle générale leurs demandes sont très opérationnelles comme dans l’ex.
Mais vous réagissez en voyant le monde par l’ornière High Tech orienté web (c’est ce que j’ai remarqué à la lecture des réactions)… or ce marché est très minoritaire en comparaison du marché global (industrie, service, etc. etc.)
Je comprends très bien votre point de vue (les 100% agilité), je l’ai dit plusieurs fois, mais j’ai l’impression que beaucoup sont incapables de changer de paradigme pour alimenter ce fil… et saisissent la moindre opportunité qui va dans son sens sans utiliser la pensée « out the box » comme je disais.
D’où l’impossibilité de dialoguer.
Tu m’as l’air plus ouvert (ça ne veut pas dire que tu partageras mon pt de vue), c’est pour ça que j’ai repris la discussion.
Voilà, c’est ce que j’ai failli ajouter dans ma précédente remarque. Hormis donc si nous sommes sur un terrain sans risque, ultra balisé, rodé, déjà fait et refait par de nombreux presta. L’agilité réduit le risque. Si il n’y a pas de risque l’agilité n’a pas vraiment de sens à mon avis et seul le prix est un facteur différenciant. Le forfait s’impose de lui-même. Voire même un prix tout court d’une offre packagée.
Je te rejoins totalement karim sur le biais culturel qui a pu s’introduire dans les conversations entre innovation et soft qui dit « papa/mamn » MAIS ces milieux ne sont pas forcément exclusifs l’un de l’autre.
Je suis entièrement d’accord, ils ne sont pas exclusifs.
D’ailleurs je terminais mon 1er post avec ceci : agile peut-être, mais dans un cadre au forfait.
Pourquoi ?
Parce que même sur du papa/maman, et surtout dans du transverse (comme dans l’ex. précèdent), des demandes de changement vont intervenir…les ends users voient que le projet est lancé, ils vont donc être dans le mouvement, se poser des questions, trouver de nouveaux besoins, les exprimer, etc.
Or, le commanditaire (direction) a déjà bouclé son offre, le presta a déjà commencé et à la livraison finale : Les ends users vont être déçu si les nouveaux besoins n’ont pas été satisfait.
Et là peu de chance pour que la direction remette de l’argent dans le projet, le budget est déjà clos (une fois livré c’est plus compliqué qu’en cours de route…c’est souvent des raisons politiques, je vais pas aller sur ce terrain ça demanderait un fil consacré).
L’insatisfaction vient souvent de là, et non pas parce que le prestataire n’a pas répondu au besoin (il l’a fait sur le contrat initial)… quelque soit la méthode utilisée.
Une des alternatives, c’est de mettre de l’agilité dans le forfait avec une technique qui existe depuis près de 40/50 ans : le rolling wave planning.
On met de l’itération dans le forfait : je présente des maquettes au fur et à mesure de l’avancement qui seront validées. (j’explique au plus simple)
Si une demande de changement intervient, on modifie le contrat par un avenant en précisant les conséquences : changement de périmètre (si pas de budget supplémentaire), modification du budget (si changement de périmètre), révision des délais.
Le client (on fait en sorte d’avoir quelques end users dans la boucle) choisi là où il fera des compromis où si on continue selon le plan initial.
On reste dans le forfait, le client garde son type de contrat hyper protecteur et le prestataire se protège et s’assure à la fin une pleine satisfaction du dit client.
on s’est un peu frités ^^, mais au final, il y a pas mal d’infos intéressantes dans le fil.
Je ne connaissais pas ce type de fonctionnement que je trouve bien pour travailler avec des structures rigides.
Et si même ces structures arrivent à intégrer les end user dans le process c’est bien.
Pour moi, si ça a déjà été fait et refait, et qu’il n’y a donc plus de ‹ custom ›, je ne vois pas l’intérêt de refaire un développement spécifique, autant installer un produit open source qui fait bien le boulot et l’utiliser (ou utiliser un saas qui fait le boulot aussi), ça coûtera moins cher.
Pour chaque entreprise, un bon de commande est différent (et spécifique en fonction du coeur de métier), pour récupérer les nomenclatures (comme décrit dans mon ex.) il faut se connecter à un SI existant, idem pour la facturation, la compta à son SI…
C’est le process qui est maitrisé (c’est ça qui est fait, refait et maitrisé): envoyer un bon de commande dans un SI, le dispaché dans les services, éditer les factures, faire de la BI bas niveau.
Le reste c’est de la technique, c’est pas là ou est la complexité.
Installer un produit open source n’est pas forcement la solution la plus adaptée:
Il faut trouver l’outil qui réponde au maximum au besoin (c’est déjà pas gagné) et les spécialistes sont rares et chers sur certains produits, la plupart d’ailleurs.
Mieux vaut parfois partir de zéro sur sur des technos très utilisées (couvertes par le max de prestataires).
Quant au Saas, se posera le problème de l’intégration avec le SI existant: et quid du cout de dev d’un EDI pour connecter le SI de la boite avec le service Saas (qui de toute façon ne couvrira pas l’ensemble du besoin… donc plusieurs services Saas pas forcement compatibles les uns avec les autres… encore une couche applicative à ajouter).
Le Saas est très bien sur des services spécifiques mais très problématique lorsque les services Saas se multiplient et qu’une intégration à un SI existant est nécessaire.
Je serais ravi d’en parler avec toi autour d’un café un de ces jours !