Les défis de la numérisation des processus administratifs
L'e-gouvernement, un moyen pour stimuler la croissance économique
La numérisation des processus administratifs dans le secteur public s’est fortement accélérée pendant la pandémie de Corona, mais il reste encore beaucoup à faire. Sur le continent africain en particulier, les obstacles administratifs sont un facteur majeur de la lenteur de la croissance économique dans de nombreux pays. La numérisation des processus administratifs tels que l’octroi de crédits ou l’accès public à des informations en ligne sur les entreprises fiables; constitue souvent une condition préalable importante pour la croissance économique.
Implication du personnel administratif dans la mise en œuvre
De plus en plus de gouvernements s’efforcent donc de numériser le secteur public, parfois avec l’aide de la Banque mondiale et d’autres organisations. Pour y parvenir, certains obstacles doivent être pris en compte. Etant donné que l’objectif final est d’améliorer les services rendus aux citoyens, il est donc nécessaire d’impliquer à la fois les fonctionnaires et les citoyens afin de développer des applications qui conviennent à tous.
En ce qui concerne les employés en particulier, il est important de les convaincre dès le départ que la nouvelle solution facilitera leur travail et ne constituera aucunement une menace pour leur emploi. Cela signifie qu’ils doivent déjà être impliqués dès l’analyse des besoins. Pour identifier leurs besoins, il est souvent nécessaire d’observer les processus existants sur place afin de pouvoir les reproduire numériquement d’une part et de les optimiser d’autre part.
Afin d’augmenter l’acceptation des nouveaux systèmes et réduire les éventuelles résistances, il est important d’élaborer une stratégie au préalable. Une formation post-implémentation particulièrement intensive, axée sur les avantages pour les utilisateurs, peut largement aider dans ce sens.
Coopération des systèmes entre les entités gouvernementales
Les exigences légales relatives aux processus administratifs constituent d’autres obstacles pour la numérisation de ces derniers. Pour pouvoir les prendre en compte de manière appropriée dans un système, une analyse et une connaissance precises des lois sont nécessaires. En outre, les domaines qui se réfèrent aux lois doivent être facilement adaptables afin de pouvoir proéder rapidement à leur mise à jour en cas de changement.
Enfin, les données manquantes ou dispersées dans des systèmes monolithiques, constituent un défi. Faciliter leur recherche grâce à des fonctions de recherche hautement performantes et migrer les données de manière à ce que toutes les exigences légales demeurent respectées nécessitent de grandes capacités de planification et une bonne compréhension des processus administratifs.
L’échange de données entre les systèmes des différentes administrations est un autre facteur de réussite important pour l’utilisation de systèmes administratifs numériques. D’une part, cela évite aux utilisateurs de devoir faire des allers-retours entre les différents sevices administratifs et, d’autre part, les informations sont directement extraites de leurs sources, ce qui garantit la précision, l’exactitude et l’actualité des données.
Savoir-faire technique et connaissance du contenu
Toutes ces raisons expliquent pourquoi les gouvernements ont souvent du mal à trouver le bon partenaire pour mettre en œuvre leur stratégie de numérisation, car les entreprises apportent rarement à la fois le savoir-faire requis pour développer un système aussi complexe et la connaissance nécessaire des conditions particulières liées à la numérisation des processus administratifs.
En conclusion, il est évident que l’expérience dans la mise en œuvre de projets d’e-gouvernement est cruciale pour éviter d’éventuels problèmes. Une connaissance précise de la législation ainsi que des procédures est également essentielle.
Contenu:
La complexité exige de nouvelles approches
Avantages des solutions personnalisées par rapport aux solutions standards
Avantages des solutions personnalisées
Les Logiciels/Solutions personnalisées, sont créés sur-mesure afin de répondre efficacement aux besoins de votre entreprise chose qui peut vous aider à gagner du temps et de l’argent sur du long terme. Bien que le développement personnalisé puisse nécessiter un investissement beaucoup plus important que le logiciel standard, il est souvent plus rentable sur du long terme. Cela parce que le développement personnalisé est conçu pour répondre avec exactitude à vos besoins spécifiques, donc vous ne payez pas pour les fonctionnalités dont vous n’avez pas besoin. De plus, le développement personnalisé est souvent plus évolutif que le standard.
L’un des plus grands avantages du développement personnalisé est sa flexibilité, votre société évolue vos besoins évolue avec, votre stratégie change vos besoins changent en conséquence, des changements rapides et de nombreuses crises mondiales, comme la pandémie de Corona ou la guerre en Ukraine.
Avec le développement personnalisé, il est facile d’ajouter de nouvelles fonctionnalités ou de modifier la façon dont fonctionnent les fonctionnalités existantes ces changement sont possibles à tout moment car il existe un contact direct avec le fabricant. Contrairement à des solutions standards, vous allez probablement acheter une solution entièrement nouvelle afin de répondre à vos nouveaux besoins.
Les inconvénients des solutions personalisées réévalués
Mais qu’en est-il des inconvénients ? À première vue, la mise en œuvre d’un nouveau logiciel semble être un long processus que beaucoup voudraient contourner. Le processus de développement est coûteux car il nécessite la collaboration et la communication d’experts de différents domaines avec l’équipe de développement.
Mais quiconque a eu affaire à l’introduction et à la mise en œuvre d’un logiciel standard sait combien d’accrocs il peut y avoir avant que le produit n’atteigne le résultat souhaité. Car « acheté rapidement » ne signifie pas que la solution fonctionnera aussi rapidement et que le produit standard apparemment moins cher deviendra vite un chantier permanent.
Les solutions existantes peuvent offrir un rapport coût-bénéfice supérieur lorsque les opérations de l’entreprise ne sont pas très complexes. Le coût augmente en fonction du niveau de complexité. Certains processus de développement de logiciels complexes nécessite une variation des langages de programmation, un excellent niveau d’expertise, les outils de développement, ainsi que les licences nécessaires à la création d’un logiciel personnalisé contribuent tous au coût global du développement.
De plus, un programme standard ne couvre souvent pas tous les besoins d’une entreprise, de sorte qu’il faut traiter avec une grande variété de fournisseurs et entretenir différents systèmes, alors qu’avec une solution logicielle sur-mesure vous répondez à tous vos besoins dans la même interface.
Réduction des coûts grâce à une planification précise et au nearshoring
En fait, il est possible que les coûts du développement d’un logiciel personnalisé dépassent le budget prévu. Cependant, une analyse et une planification précises des besoins ainsi qu’un suivi strict du budget peuvent éviter une explosion des coûts dès le début. Des économies supplémentaires peuvent être réalisées en faisant appel à un partenaire qui a externalisé son développement de logiciels dans une région de nearshoring. En outre, le bilan est rapidement différent lorsqu’on compare un logiciel personnalisé à un produit standard, si l’on tient compte de la maintenance, des mises à jour du logiciel, des licences, etc.
Une collaboration étroite avec une entreprise spécialisée dans le développement de solutions logicielles complexes permet donc aussi d’éviter les malentendus sur ce que le produit fini doit pouvoir faire et réaliser. Le mode de travail agile des entreprises de logiciels, qui permet aux développeurs de réagir rapidement à l’évolution des besoins, y contribue également.
Conclusion : Le logiciel sur-mesure est la solution de choix dans les environnements complexes.
Certes, dans certains cas, il peut être judicieux de choisir un logiciel standard. La question de la complexité de ses propres structures et processus, basée sur le cadre Cynefin, aide à la décision. En particulier à l’ère de la numérisation, les défis sont rarement simples, de sorte que l’approche d’une solution de meilleure pratique ne s’applique plus. Car dans un monde Vuca complexe, ce qui compte, ce sont les procédures et les structures qui peuvent être adaptées facilement et rapidement. Une solution adaptée aux besoins du client qui a déjà fait face aux défis particuliers de l’entreprise lors de son développement est bien plus utile, bénéfique et orienté qu’une solution développée pour des cas standards. Cela reste valable même si l’expérience de nombreux secteurs d’activité a été prise en compte.
Contenu:
Nearshoring en Tunisie : est-ce possible?
Six réserves réévaluées
De nombreuses entreprises en Europe font désormais appel à des partenaires de nearshoring pour externaliser le développement de logiciels ou l’ensemble de leurs processus métier en raison du manque Le manque de ressources internes au regard de la complexité de l’évolution des technologies et des coûts de main-d’œuvre élevés. Le choix classique est la Pologne, la Bulgarie ou l’Ukraine. Mais des endroits comme la Tunisie deviennent également de plus en plus importants dans ce contexte.
Cependant, Il existe toutefois encore des réserves à l’égard des partenaires non européens, qui peuvent facilement être réfutées, car le nearshoring en Tunisie offre également de nombreux avantages.
Formation de qualité et proximité géographique
Qualité: En Tunisie, l’enseignement supérieur est de grande qualité et absolument comparable aux pays d’Europe occidentale. 240 000 étudiants sortent chaque année de l’enseignement supérieur, dont 20 000 ingénieurs et scientifiques et 9 000 diplômés en technologies de l’information et de la communication. La Tunisie compte plus de 50 écoles d’ingénieurs qui enseignent l’informatique, entre autres matières. Cela garantit une haute qualité dans la mise en œuvre de projets logiciels.
Distance: Même si la Tunisie est située sur un autre continent, le décalage horaire est d’une heure maximum et le vol dure à peine deux heures. Ainsi, contrairement à la délocalisation dans des pays comme l’Inde, en Tunisie vous avez la garantie que vos interlocuteurs sont disponibles pendant les heures de bureau européennes pour prendre des dispositions ou résoudre des problèmes.
Multilinguisme et infrastructure stable
Communication: une grande partie de la population tunisienne parle couramment le français, l’anglais est enseigné à l’école à partir de la 4e année et il existe des institutions linguistiques certifiées et professionnelles pour la langue allemande. Pour les professions techniques, le français et l’anglais peuvent être assumés, l’allemand et l’italien s’y ajoutent souvent. La distance locale peut être comblée sans problème grâce aux moyens de communication numériques, qui se sont encore développés pendant la pandémie de Corona. La bonne infrastructure de télécommunications, dont la Tunisie est le leader dans le sud de la Méditerranée, y contribue également.
Mentalité: Il existe sans aucun doute des différences entre les mentalités allemande et tunisienne. Cependant, des entreprises telles que think tank Business Solutions disposent d’une expérience de plusieurs décennies dans la réalisation de nombreux projets avec des partenaires européens. Une tête de pont allemande composée de Product Owners et de consultants garantit en outre le bon déroulement de la coopération avec les clients.
Mentalité "hands-on" et réduction des coûts
Pilotage: le pilotage d’un projet est toujours un défi, surtout lorsqu’il s’agit de diriger une équipe hybride et multinationale. Pour garantir le bon déroulement d’un projet, un modèle de travail agile s’impose, notamment pour le développement et la mise en œuvre de logiciels dans des entreprises comme le think tank, y compris en Tunisie. Le pilotage des projets par des collègues allemands permet de garantir que les exigences des clients restent toujours au centre des préoccupations. En outre, les développeurs en Tunisie ont, tout comme leurs collègues dans d’autres pays, une mentalité « Get the job done » et agissent en fonction des objectifs.
Coûts : La Tunisie est également une très bonne alternative en termes de coûts. Les taux horaires pour un employé tunisien sont attractifs et compétitifs. Malgré la bonne qualité du marché du travail, les coûts salariaux moyens pour un employé à temps plein, par exemple, sont très faibles – en comparaison avec les pays d’Europe de l’Est, ce qui fait de Tunis un site nord-africain attrayant pour l’externalisation des processus d’affaires.
Il ne faut pas oublier qu’avec la Tunisie, nous sommes dans une zone politiquement stable, alors que dans la région de l’Europe de l’Est, a connu des tensions et des incertitudes ces derniers temps.
Le meilleur des deux mondes
Dans l’ensemble, on peut constater que la Tunisie représente une bonne alternative aux pays classiques d’Europe de l’Est en tant que partenaire de nearshoring. En combinaison avec une tête de pont allemande, qui peut, si nécessaire, faire office de traducteur non seulement de la culture, mais aussi de la mentalité, on mise sur le meilleur des deux mondes : Disponibilité de la main-d’œuvre qualifiée, réduction des coûts et savoir-faire allemand avec une qualité allemand.
Contenu:
Tests dans le développement de logiciels
Les erreurs et comment les éviter
Les arguments fréquents contre les tests approfondis dans le développement de logiciels sont qu’ils ne sont pas nécessaires, car l’entreprise accorde une grande importance à la qualité du travail. Cela permettrait d’économiser de l’argent sur les tests logiciels. . En y regardant de plus près, cependant, il devient rapidement clair que ces deux points peuvent être réfutés très rapidement.
Conséquences: Des fonctionnalités manquantes et des utilisateurs finaux insatisfaits
L’or de la communication entre le client et le développeur, des malentendus peuvent survenir dans différentes étapes de la mise en place du projet, de sorte qu’au final on a un redu soit avec des manquements de fonctionnalités soit il ne répond pas au besoin souhaité. En outre, on ne peut pas négliger le facteur humain, C’est-à-dire que même avec la meilleure expertise ou la meilleure compétence, l’erreur humaine peut surgir. De plus, les modifications apportées à un système existant peuvent entraîner des dysfonctionnements ailleurs, qui n’apparaissent que lorsqu’un utilisateur final s’en plaint.
Et cela nous amène directement aux conséquences sur les entreprises qui économisent sur les tests. Les erreurs peuvent entraîner l’insatisfaction des clients et donc une perte de crédibilité et de notoriété. A cela s’ajoute le fait que les bugs qui apparaissent après la sortie doivent être corrigés le plus rapidement possible. Par conséquent Les développeurs seront bloqués pendant ce temps et ne pourront pas continuer à travailler sur le développement de nouvelles fonctionnalités, ce qui retardera le développement du projet par conséquent des coûtes supplémentaire qui auront dû être économisé grâce aux tests.
À faire: Démarrer à temps et répartir les rôles.
Tout cela montre clairement que les tests sont un correctif nécessaire dans tout développement de logiciel. . Mais à quoi devriez-vous faire attention dans les tests logiciels et que devriez-vous éviter? Il est important de créer les cas de test à temps, c’est-à-dire dès la création des User Stories. Dans le meilleur des cas, une équipe de test indépendante en est responsable, qui n’est pas trop impliquée dans le développement, afin d’exclure une certaine cécité opérationnelle. Il en va de même pour l’exécution des tests. On ne peut être juge et partie .Il est préférable donc que personne ne teste ses propres cas de test, mais toujours ceux que quelqu’un d’autre a créés. En outre, cela permet d’éviter que le Product Owner, qui doit approuver la version et donc tous les cas de test, ne crée un goulet d’étranglement qui peut entraîner des retards.
Il est essentiel de veiller à une bonne élaboration des cas de test. Cela signifie que les cas de test doivent être élaborés sur la base des User Stories et, dans le meilleur des cas, couvrir toutes les étapes qui y sont mentionnées. Les tests devraient également commencer immédiatement après la mise en œuvre de la User Story par le développeur, afin de pouvoir respecter la date de sortie. Chaque test doit également inclure un rapport de test dans lequel est consigné avec précision ce qui a fonctionné et ce qui n’a pas fonctionné, afin de garder un historique ainsi qu’une vue d’ensemble des erreurs survenues au cours d’un sprint de développement. L’automatisation des cas de test pour les cas d’utilisation standard, par exemple « je peux télécharger un texte » ou pour les erreurs qui reviennent régulièrement, peut-être d’une grande aide.
Prévoir 20% du volume du projet pour les tests logiciels
Bien sûr, les tests ne doivent pas être excessifs, une couverture de test de 95% annule toutes les économies de coûts, car un tel taux ne peut être atteint que par des tests intensifs. 20% du volume du projet est une bonne ligne directrice à suivre lors de l’introduction d’une procédure de test. Il est toutefois inutile de vouloir économiser de l’argent en testant moins, car cela n’en vaut pas la peine en raison d’une perte de crédibilité possible, de l’engagement de ressources lors du développement pour la correction de bugs et de la sortie retardée d’une application en aval qui en résulte.
Contenu:
Tests agile dans le développement de logiciels
La voie vers plus de qualité et d'efficacité
Avec la mise en place de méthodes agiles, les besoins des utilisateurs sont au cœur du développement logiciel. Les futurs utilisateurs sont davantage impliqués dans le processus de développement .et garantissent par leurs contributions, à ce que les thèmes importants soient effectivement mis en œuvre et à ce que l’application soit facile à utiliser et efficace. Pour le vérifier, un logiciel fonctionnel et sans erreur doit être livré souvent et continuellement. Les exigences élevées posées à la partie non fonctionnelle du logiciel doivent également être testées en permanence : le code est-il clair, l’application est-elle conforme aux exigences de sécurité, est-elle stable et facile à maintenir? En une phrase : une livraison de code constante, fréquente et sans erreur est une question de qualité.
Qu’est-ce qui distinguent les tests agiles des tests classiques ?
Dans la gestion classique des tests, le développement et les tests sont clairement séparés et les quatre étapes de test se déroulent l’une après l’autre . La phase de test débute à l’achèvement du produit. Les différents composants sont d’abord testés (test des composants).l’étape suivante, le test d’intégration, permet de vérifier l’interaction entre les différents composants.Pour finalement tester sous tous les angles les fonctions du produit entier, d’abord en interne (système d’essai) . et enfin. le client (test d’acceptation par l’utilisateur.
Les rôles sont clairement répartis. L’équipe de développement développe, l’équipe de test teste et la gestion des tests contrôle et gère. Pour une livraison continue (à chaque itération). des logiciels stables et exempts d’erreurs dans un environnement agile, des tests permanents sont nécessaires. Il n’est pas possible à long terme de passer d’une étape de test à une autre à l’aide de méthodes de test conventionnelles, car les itérations sont courtes et rapides. En test agile, il y a aussi des tests de composant, d’intégration et de système, à la différence qu’ils ne s’exécutent pas l’un après l’autre. mais parallèlement à une itération, et sont même parfois intégrés au développement.
L’approche agile ne connaît pas non plus de rôles clairement répartis. Idéalement, les développeurs de logiciels et les architectes ainsi que les testeurs. Les responsables des tests et de la qualité font partie de l’équipe de développement et se soutiennent les uns les autres. L’équipe a un objectif commun : une qualité élevée avec une couverture de test élevée, une exécution et une documentation efficaces. Pour ce faire, il faut trouver le juste équilibre entre un haut niveau d’automatisation et peu de tests manuels.
Répartition efficace des tests : la pyramide des tests
Un coup d’œil sur la pyramide de test de Mike Cohen montre comment concevoir une stratégie de test efficace. Comment planifier la répartition des tests sur les différents niveaux de test et quels domaines se prêtent le mieux à l’automatisation des tests. La large base de la pyramide est constituée par un nombre élevé de tests de composants sous forme de tests unitaires automatisés. Ceux-ci sont relativement faciles à créer en parallèle avec le développement de l’application, rapides à réaliser, peu coûteux et garantissent une couverture de test élevée.
Ils décèlent la plupart des erreurs au stade du développement. Les tests d’intégration (tests API) constituent le niveau intermédiaire de la pyramide de test. API signifie Application Programming Interfaces. Les tests API automatisés garantissent que les composants fonctionnent ensemble comme prévu. Les tests API sont très bien adaptés à l’automatisation des tests, car ils sont généralement soumis à peu de modifications et sont faciles à entretenir. Il convient de noter que les tests non fonctionnels, tels que les tests de charge et de performance, ne sont pas pris en compte dans la pyramide de test par contre ils sont importants pour l’acceptation par l’utilisateur et qu’ils peuvent en partie être très bien automatisés.
Les tests système (tests GUI) se trouvent au sommet de la pyramide. On appelle GUI (Graphical User Interface) l’interface utilisateur graphique. Les tests GUI automatisés vérifient si toutes les fonctions se déroulent comme prévu. Leur automatisation est facilement réalisable grâce à une sélection d’outils, mais le choix des tests à automatiser doit être étudié avec soin, car ils sont plus complexes à créer et à entretenir par conséquent plus coûteux. En règle générale, les tests de l’interface graphique nécessitent des d’importantes retouches pour pouvoir suivre les changements fréquents.
Il est recommandé d’automatiser autant de tests que nécessaire et aussi peu que possible et de les introduire progressivement, par exemple en sécurisant les fonctions existantes au moyen de tests de régression automatisés sprint après sprint. Les tests exploratoires et les tests de bout en bout ne se prêtent guère à l’automatisation des tests en raison de leur complexité et pour les tests exploratoires en raison de leur degré de liberté. Le testeur exploratoire explore l’application sans avoir déterminé au préalable quelles étapes de test doivent être exécutées. L’avantage est qu’il y a moins de préparation, que la documentation est réduite au minimum et que les erreurs sont trouvées en dehors des scénarios de test existants.
Sources: Livre: Agile Testing: Manfred Baumgartner, Martin Klonk, Helmut Pichler, Richard Seidl, Siegfried Tanczos (2018): Der agile Weg zur Qualität
