La comptabilité du développement logiciel
Le coût d’un développement logiciel est généralement imputé dans les éléments capitalisables qui correspondent à un investissement (CAPEX). Il est donc amortissable sur plusieurs années, tout comme le montant de la camionnette de l’artisan qui est prise pour exemple dans les cours de comptabilité.
On commence à amortir le coût du logiciel quand il est effectivement mis en production. Et tout cela marche bien avec les modes de développement classiques en cascade : de la conception à la mise en production.
Mais, quand les développements sont faits avec un flux de mise en production quotidienne et que le logiciel est un site web, les choses se compliquent. Si, pour une raison ou une autre, vous souhaitez affecter en CAPEX et non en OPEX les coûts de développement : vous pouvez toujours effectivement les passer en CAPEX, dans la mesure où c’est toujours un investissement dont vous espérer tirer des bénéfices ultérieurement.
Seulement voilà : pour pouvoir les passer en CAPEX il faut pouvoir les amortir, disons sur 3 ans. Or, la plupart des features que vous mettez en production n’ont pas forcément cette espérance de durée de vie. Quel intérêt de mettre en CAPEX du développement de features qui vont être remplacées par de nouvelles features quelques semaines plus tard ?
Pas encore trouvé de solution pour justifier de bonne foi comment un flux de mise en production quotidienne de features peut être passé en CAPEX quand il a une durée de vie incommensurable avec les délais d’amortissement autorisés. Agile et continuous deployment mettent le plan comptable à rude épreuve.
Bonsoir,
Dans la boîte pure-player dans laquelle je travaille depuis 11 ans maintenant, on a mis en place un système qui me parait bien :
Chaque tache mise au planning a une durée estimée au départ. Puis la durée réelle est saisie quand elle est finie, et se voit agrémentée d’un autre attribut : maintenance ou développement.
A côté de cela, on a défini un attribut « R&D », afin de pouvoir comptabiliser le temps passé en R&D, et bénéficier justement du crédit impôt recherche.
[Reply]
En général, quand on se lance dans un développement, on se dit **en toute bonne foi**, que le produit sera en ligne au moins trois ans 🙂
Chez nous, une tâche est un peu plus générique qu’une User Story : disons simplement qu’une tâche est :
– une proposition qui a été validée (chez nous, par le DG, car la décision est centralisée. J’aimerais que ce soit autrement :o) ). La fonctionnalité doit être développée et mise en ligne
– un bug rapporté. Il est immédiatement considéré comme une tache, sans passer par la validation. Si le bug est rattaché au développement en cours, la durée sera activée. Si le bug est de l’ordre de la maintenance, elle ne le sera pas.
Vient ensuite la segmentation de la tache en sous-taches … etc, etc, …
[Reply]
Christian Reply:
février 9th, 2014 at 11:15
Merci pour le conseil.
Qu’est-ce que tu appelles une « tâche » ? C’est une User Story ?
[Reply]