L’absence de cette mesure initiale pourrait rendre difficile la séparation correcte des coûts entre ceux qui devraient être capitalisés et ceux qui devraient être passés en charges. Cela pourrait entraîner des erreurs dans l’application des PCGR ainsi que des erreurs dans le montant du résultat net déclaré par les entités., Cet article est conçu pour aider les lecteurs à répondre à cette question: Quels coûts de logiciels doivent être capitalisés et quels coûts doivent être passés en charges lorsqu’une entité construit un logiciel à usage externe à l’aide d’un environnement de développement agile?
La tendance vers le développement agile
La méthode de développement logiciel connue sous le nom d’agile est devenue populaire dans l’industrie du logiciel ces dernières années., Parce que l’approche agile (voir le graphique « Approche agile”) est largement perçue comme étant plus rapide et plus réactive aux exigences en évolution rapide, de nombreuses entreprises l’utilisent maintenant comme une alternative préférée à l’approche traditionnelle de développement en cascade.
L’approche conventionnelle de développement en cascade consiste à organiser un projet en une série de phases traditionnelles, telles que la conception, l’initiation, l’analyse, la conception, la construction, les tests, la production et la mise en œuvre, et la maintenance., Ces phases sont marquées par des activités, que le guide utilise comme cadre pour tirer une conclusion sur le moment où la faisabilité technologique est atteinte et où les coûts du projet de développement logiciel peuvent être capitalisés.
Sous un modèle agile, en revanche, un projet est organisé en modules séparés, et le travail de développement et de test sur ces modules se fait en sprints courts., L’identification du moment où les activités traditionnelles de l’approche en cascade se produisent nécessite une analyse et un jugement importants dans le développement agile, ce qui peut rendre plus difficile l’application des directives PCGR pour la capitalisation des dépenses.
En fin de compte, les modèles agile et waterfall peuvent produire un projet réussi; cependant, déterminer le point dans le processus de développement logiciel pour commencer et terminer la capitalisation des coûts peut être plus difficile avec le modèle agile.,
2 ensembles de règles de capitalisation logicielle
Comme point de départ pour capitaliser correctement les coûts de développement logiciel, il est important de déterminer les directives appropriées. Selon les PCGR des États-Unis, deux ensembles potentiels de règles majeures peuvent s’appliquer pour déterminer si les coûts de développement de logiciels doivent être capitalisés ou passés en charges.
Un ensemble de règles (FASB Accounting Standards Codification (ASC) Topic 985, Software) est conçu pour les coûts de logiciels que l’entité a l’intention de vendre ou de louer., Ces règles, communément appelées règles de capitalisation logicielle pour les logiciels à usage externe, sont l’objet principal de cet article. L’autre ensemble de règles (NCP Sujet 350, Incorporels — Goodwill et Autres) régit les logiciels que l’entité n’a pas l’intention de vendre ou de louer. Ces règles sont communément appelées règles de capitalisation logicielle pour les logiciels à usage interne.
Il est important de noter que le seuil de capitalisation est inférieur pour les logiciels à usage interne., En vertu des règles relatives aux logiciels à usage interne, les coûts de développement peuvent généralement être capitalisés après la fin de l’étape préliminaire du projet. Le seuil pour les coûts de développement de logiciels pour la vente externe ou la licence — l’objet de cet article — est plus strict, ce qui signifie qu’une analyse plus approfondie est nécessaire pour déterminer quels coûts de développement doivent être capitalisés.
Lorsque les PCGR et agile ne sont pas alignés
Sous la rubrique 985, la question cruciale pour déterminer si les coûts de développement de logiciels à usage externe doivent être capitalisés tourne autour du terme « faisabilité technologique.,” Tous les coûts de développement de logiciels engagés avant le moment où le projet a démontré sa faisabilité technologique devraient être passés en charges au fur et à mesure qu’ils sont engagés.
Une fois que la faisabilité technologique a été établie, la plupart (mais pas tous) des coûts de développement peuvent être capitalisés. Enfin, une fois le développement terminé et le logiciel mis à la disposition des clients, la capitalisation n’est plus appropriée car les coûts restants sont considérés comme une maintenance et un support continus. Ces coûts doivent être comptabilisés en charges lorsqu’ils sont encourus.,
La définition de « faisabilité technologique” est donc le facteur critique pour déterminer quand une entreprise doit commencer à capitaliser ses coûts de développement. Le sujet 985 dit: « la faisabilité technologique d’un produit logiciel est établie lorsque l’entité a terminé toutes les activités de planification, de conception, de codage et de test nécessaires pour établir que le produit peut être fabriqué pour répondre à ses spécifications de conception, y compris les fonctions, les caractéristiques et les exigences de performance technique.,” Il est également important de noter que les coûts de développement de logiciels sont soumis à ces règles, que les coûts aient été générés en interne (comme le temps des employés) ou en externe (comme les frais des fournisseurs).
Dans les projets de développement de logiciels classiques avec des phases consécutives bien définies, la faisabilité technologique est généralement démontrée par une conception de programme détaillée ou, en l’absence de conception de programme détaillée, un modèle de travail prêt à être testé par le client. Ce sont des jalons familiers pour les projets utilisant l’approche en cascade.,
Dans un environnement de projet agile, cependant, les fonctions et fonctionnalités individuelles sont développées séparément dans une série de sprints. Chaque sprint ou module est envisagé, planifié, financé, développé et testé individuellement pour être intégré dans le projet global lorsqu’il est prêt.
Dans un tel environnement, la conception de programmes complets ou les modèles de travail sont souvent peu pratiques ou non pertinents., Les entreprises utilisant une approche agile pour développer des logiciels pourraient conclure de manière inappropriée que la faisabilité technologique n’a pas été atteinte de manière significative avant que l’amélioration logicielle ne soit disponible pour les clients, ce qui a pour conséquence que les coûts sont passés en charges au lieu d’être capitalisés. Si des coûts importants s’accumulent entre le moment où la faisabilité technologique a réellement été atteinte et le moment où le logiciel est disponible pour les clients, la comptabilité qui en résulte pourrait être incompatible avec les PCGR.,
Application des PCGR dans un environnement agile
Bien que les directives PCGR actuelles pour les logiciels à usage externe ne soient pas adaptées à l’environnement agile, cela ne signifie pas que les coûts de développement agile ne peuvent pas être capitalisés du tout. Il y a, après tout, différents niveaux d’agilité. Alors qu’un projet agile pur peut commencer avec juste une idée et relativement peu de travail de conception, certains projets agiles ont des conceptions de programme détaillées avec un storyboarding approfondi, des études d’acceptation du marché et d’autres documents de travail de conception mis en place avant le début du développement réel., Ces documents pourraient être utilisés pour aider à évaluer la faisabilité technologique.
Le point critique à retenir est que, pour évaluer les coûts qui devraient être capitalisés, il doit y avoir suffisamment de planification de projet pour démontrer que les critères d’une « conception détaillée du programme” ont été respectés. Le risque est que les équipes de projet ne fassent pas assez de planification initiale ou ne conservent pas suffisamment de documents pour démontrer qu’elles ont atteint ce seuil., La démonstration de la faisabilité technologique exigera probablement que l’équipe de projet fasse plus de planification et compile plus de documentation que ce qui est typique dans la plupart des projets agiles.
D’autres considérations importantes lors de la détermination de la faisabilité technologique concernent les caractéristiques de développement à haut risque. Par exemple, le projet est-il une plate-forme logicielle complètement nouvelle, ou s’agit-il d’une amélioration ou d’une recréation de quelque chose qui a été fait auparavant? L’entreprise développe-t-elle des logiciels à partir de zéro ou rassemble-t-elle divers composants logiciels qui existent déjà?, Les caractéristiques de développement à haut risque peuvent nécessiter une analyse supplémentaire du moment où la faisabilité technologique est atteinte et, dans certains cas, une comptabilisation en charges des coûts précédemment capitalisés.
Les améliorations de produits qui ne sont pas considérées comme des activités de maintenance peuvent parfois atteindre le seuil de faisabilité technologique plus facilement parce que les développeurs ajoutent des fonctions à un produit déjà réussi. Dans de tels cas, les facteurs décisifs comprennent le type de logiciel, le niveau de modification requis et le niveau de travail de conception terminé avant le début du développement.,
Même lorsque la faisabilité technologique est établie, tous les coûts de développement agile ne peuvent pas être capitalisés. Dans la plupart des cas, seuls certains des coûts de chaque sprint peuvent être capitalisés. Les coûts qui ne devraient pas être capitalisés comprennent l’analyse initiale, l’acquisition de connaissances, la planification initiale du projet, le prototypage et le travail de conception comparable qui doit être effectué pour comprendre les caractéristiques et la faisabilité souhaitées du produit.
Mais une grande partie des coûts engagés pour développer et tester de telles fonctionnalités devrait souvent être capitalisée si la faisabilité technologique est atteinte., Ces coûts comprennent le codage réel, les tests et les coûts de main-d’œuvre associés.
Gardez cependant à l’esprit que tous les coûts liés à la maintenance ou à la correction d’erreurs encourus pendant le sprint peuvent devoir être passés en charges plutôt que capitalisés, car de nombreuses activités pendant le sprint peuvent ne pas être du codage et des tests, mais peuvent être des activités telles que le dépannage et la découverte. De plus, la capitalisation se termine une fois que le projet est terminé et que le logiciel est prêt à l’emploi.,
La distinction entre les coûts qui peuvent être capitalisés et ceux qui ne peuvent pas être capitalisés peut compliquer quelque peu les étapes de comptabilité, de reporting et de documentation du projet au sein de chaque sprint. Mais le travail administratif supplémentaire ne doit pas nécessairement être onéreux. Dans la plupart des cas, les différentes tâches et livrables de chaque sprint peuvent être segmentés en grandes catégories, de sorte que tous les coûts associés à cette tâche peuvent être passés en charges ou capitalisés.,
Préparation et communication: Les étapes critiques
Décider quels coûts de développement de logiciels à usage externe peuvent être capitalisés dans un environnement de projet agile implique un certain jugement. Dans de nombreux cas, les faits et circonstances spécifiques entourant le type de logiciel en cours de développement entraîneront le traitement des coûts. Une planification minutieuse peut aider à l’analyse des coûts à capitaliser par rapport aux dépenses.,
Pour cette raison, il est généralement conseillé de discuter du traitement comptable avec l’équipe de gestion de projet et les experts en la matière avant de commencer tout projet de développement d’envergure. Il est également important de comprendre dès le début d’un projet le niveau de soutien et de documentation qui sera nécessaire pour permettre les décisions appropriées concernant la capitalisation des coûts. De plus, il faut bien comprendre le niveau de documentation qui devra être conservé pour que les vérificateurs puissent évaluer et confirmer les décisions de capitalisation et d’imputation.,
Par exemple, l’équipe du projet devrait documenter en détail le rôle de chaque personne dans le projet afin que la comptabilité puisse faire la distinction entre les personnes dont le temps et les activités pourraient potentiellement faire l’objet d’une capitalisation et celles dont les activités n’entreraient jamais dans cette catégorie. Il est également important de maintenir des contrôles internes supplémentaires tels que des examens mensuels des activités, des montants capitalisés et passés en charges et des modèles de communication que les gestionnaires de projet peuvent remplir pour vérifier que le temps des employés est codé correctement.,
Bien que l’industrie ait discuté de la mise à jour des normes pertinentes pour les rendre plus applicables au cadre agile, de telles mises à jour impliquent généralement plusieurs années de planification, de discussion, de propositions et de rétroaction de l’industrie. Cela signifie que, dans un avenir prévisible, les entreprises qui utilisent un modèle agile pour développer des logiciels destinés à la vente ou à la concession de licences externes devront continuer à coordonner étroitement leurs équipes comptables pour appliquer les directives PCGR existantes et capitaliser les coûts de développement de manière appropriée.
Laisser un commentaire