Erreurs fréquentes sur ServiceNow au Maroc : les détecter et les corriger

Commencer par vérifier le contexte

Avant de chercher une solution à une erreur ServiceNow, notez précisément où et quand elle se produit. Relevez l’instance utilisée, par exemple développement, test ou production, le nom de l’application ou du module, l’action effectuée et le résultat attendu. Si vous ne connaissez pas la version ou les paramètres de l’instance, demandez-les à l’administrateur plutôt que de les déduire d’une capture d’écran.

Vérifiez aussi votre rôle et vos droits. Une page absente, un bouton indisponible ou un enregistrement introuvable peut s’expliquer par des autorisations, une portée d’application ou une configuration différente, et pas nécessairement par une panne. Notez si le problème touche un seul utilisateur, un groupe ou tout le monde. Cette comparaison aide à distinguer un accès individuel d’un problème plus général.

Rassemblez les éléments utiles au diagnostic : nom de la table ou du formulaire, critères de recherche, données de test anonymisées, heure approximative, message affiché et étapes juste avant l’incident. Pour une automatisation, relevez aussi le déclencheur, les conditions et l’action attendue. Ne copiez pas de données personnelles ou confidentielles dans un document partagé.

• Environnement et instance concernés.
• Application, module, formulaire ou table impliqués.
• Utilisateur ou rôle utilisé, sans partager de mot de passe.
• Étapes effectuées et résultat obtenu, comparés au résultat attendu.
• Message d’erreur exact, expurgé de toute information sensible.

Repérer les erreurs de configuration

Un problème de paramétrage apparaît lorsque la plateforme n’est pas configurée comme le scénario l’exige. Un utilisateur qui ne voit pas un champ peut, par exemple, manquer du rôle adapté ou rencontrer une règle d’accès. Une automatisation qui ne se déclenche pas peut être désactivée, associée à de mauvaises conditions ou dépendre d’un événement qui ne s’est pas produit. Il faut vérifier ces possibilités avant de réécrire le processus.

Autre cas courant : travailler dans la mauvaise instance ou dans la mauvaise portée d’application. Une modification peut sembler avoir disparu si elle a été faite ailleurs, ou si elle n’a pas été transférée dans l’environnement de test. Confirmez l’instance, l’application sélectionnée et le statut de la modification avec la procédure de l’équipe. Évitez de corriger directement la production sans autorisation et sans plan de validation.

Les résultats inattendus peuvent également venir des données de test. Un formulaire peut se comporter correctement pour un enregistrement et pas pour un autre si un champ obligatoire est vide, si une valeur de référence est différente ou si les conditions ne sont pas réunies. Comparez un cas qui fonctionne avec un cas en échec, en ne modifiant qu’un élément à la fois.

Pour séparer configuration et méthode, posez-vous cette question : les règles, accès et conditions sont-ils conformes à ce qui a été défini ? Si non, investiguez le paramétrage. Si oui, examinez l’ordre des étapes, les données saisies et la façon dont le test a été exécuté. Les deux causes peuvent aussi se cumuler.

• Symptôme : un utilisateur ne voit pas un champ. À vérifier : rôle, droits d’accès, conditions d’affichage et formulaire utilisé.
• Symptôme : une automatisation ne démarre pas. À vérifier : activation, déclencheur, conditions et données nécessaires.
• Symptôme : la modification n’apparaît pas dans les tests. À vérifier : instance, portée de l’application et transfert selon le processus de l’équipe.
• Symptôme : le résultat varie selon l’enregistrement. À vérifier : valeurs des champs, références et conditions réellement réunies.

Corriger les erreurs de méthode

Une erreur de méthode vient de la manière de construire ou de tester une solution, même lorsque la configuration est correcte. Modifier plusieurs règles à la fois est l’un des pièges les plus fréquents : si le comportement change, il devient difficile de savoir quelle modification en est responsable. Travaillez par petits changements, consignez-les et testez après chacun.

Évitez de confondre le résultat visible avec la cause. Si un formulaire ne s’enregistre pas, vérifiez d’abord les champs obligatoires, les messages, les droits et les conditions applicables. Si une recherche ne renvoie rien, contrôlez les filtres et les données avant de conclure que la table est vide. Reproduisez le problème avec un cas simple et connu.

Une autre mauvaise pratique consiste à tester uniquement le scénario qui vient d’être corrigé. Une règle d’accès ou une condition de flux peut aussi affecter d’autres utilisateurs ou enregistrements. Préparez au minimum un cas attendu, un cas limite pertinent et un cas qui fonctionnait auparavant. Faites valider les tests nécessaires selon les règles de votre organisation.

Enfin, ne copiez pas à l’aveugle une solution trouvée dans un ancien échange ou un autre environnement. Le contexte, la version, les rôles et les personnalisations peuvent différer. Consultez la documentation adaptée à votre situation et faites confirmer les changements sensibles par une personne habilitée.

• Modifier une seule cause possible à la fois.
• Décrire le résultat attendu avant de tester.
• Comparer un scénario en échec à un scénario équivalent qui fonctionne.
• Répéter les tests après chaque changement et noter le résultat.
• Faire relire les changements qui touchent les accès, les automatisations ou la production.

Contrôler les fichiers et les résultats

Avant de conclure que la correction a fonctionné, contrôlez la sortie dans l’interface et, si le processus en prévoit, dans les éléments associés : enregistrement créé ou mis à jour, historique, tâche générée ou résultat de l’automatisation. Vérifiez que les champs attendus contiennent les bonnes valeurs et qu’aucune information n’a été écrasée ou omise.

Pour les imports et les données préparées dans des fichiers, comparez le nombre de lignes source et les résultats traités, puis examinez les rejets et les valeurs manquantes. Contrôlez les colonnes de correspondance, les formats, les doublons et les champs obligatoires. Faites ces vérifications sur un échantillon autorisé avant de lancer une opération plus large.

Conservez une trace claire des essais : date, environnement, changement effectué, cas de test et résultat. La trace doit suffire à comprendre ce qui a été vérifié, sans contenir de secret, de données personnelles ou de capture montrant des informations confidentielles. Si votre organisation dispose d’une procédure de validation ou de transfert, suivez-la.

• Le résultat correspond-il exactement au besoin annoncé ?
• Les champs attendus ont-ils été créés ou mis à jour sans altérer les autres ?
• Les rejets, doublons et valeurs manquantes ont-ils été examinés ?
• Les cas voisins et les droits concernés ont-ils été retestés ?
• La modification et le résultat sont-ils documentés sans données sensibles ?

Diagnostiquer une erreur étape par étape

Une checklist progressive évite de passer directement à une modification risquée. Gardez le même ordre pour les erreurs récurrentes : contexte, reproduction, isolement, vérification, correction, retest et documentation. Si le symptôme disparaît sans que vous sachiez pourquoi, ne considérez pas encore l’analyse comme terminée : il faut pouvoir expliquer la cause probable et confirmer que la solution tient dans des conditions comparables.

• 1. Décrire : noter le symptôme, le résultat attendu et le résultat observé.
• 2. Situer : confirmer l’instance, l’application, le module, le rôle et les conditions du test.
• 3. Reproduire : refaire les mêmes étapes avec des données de test autorisées.
• 4. Isoler : comparer un cas en échec et un cas fonctionnel, puis ne faire varier qu’un facteur.
• 5. Vérifier : examiner droits, paramètres, conditions, données et documentation correspondant au contexte.
• 6. Corriger : appliquer une modification limitée dans l’environnement approprié, selon les règles de l’équipe.
• 7. Retester : vérifier le cas initial, les cas voisins et les effets possibles sur le processus.
• 8. Documenter : noter la cause retenue, la correction, les tests et les résultats.

Savoir quand demander de l’aide

Demandez de l’aide lorsque le problème touche la production, les droits d’accès, des automatisations importantes ou des données que vous n’êtes pas autorisé à modifier. Faites de même si vous ne pouvez pas reproduire le symptôme, si plusieurs équipes sont concernées, ou si une première correction a créé un nouvel effet inattendu. L’objectif n’est pas de transmettre un grand volume de captures, mais de permettre à un collègue ou à un formateur de comprendre le scénario.

Pour documenter une erreur reproductible, écrivez une fiche courte : contexte et instance, rôle utilisé, prérequis, étapes numérotées, résultat attendu, résultat observé, message d’erreur expurgé, fréquence et vérifications déjà tentées. Mentionnez les changements récents si vous les connaissez. Joignez uniquement des captures anonymisées et approuvées par votre organisation.

Ne communiquez jamais de mot de passe, jeton d’accès, données personnelles, dossiers clients, informations de production ou identifiants sensibles dans un forum ou un espace public. Si ces éléments sont nécessaires à l’analyse, utilisez le canal interne prévu et demandez les consignes de sécurité de votre organisation. Une description claire et anonymisée permet souvent de commencer le diagnostic sans exposer ces données.

• Indiquez les étapes exactes, dans l’ordre, et ce qui se passe à chaque étape.
• Précisez ce que vous avez déjà vérifié et les changements effectués.
• Ajoutez une capture seulement si elle est autorisée et anonymisée.
• N’envoyez jamais de secrets, mots de passe ou données identifiantes dans un forum public.

Le parcours, étape par étape

1. 1Définir le symptôme — Écrivez ce qui devait se produire et ce qui s’est réellement produit. Évitez les formulations générales comme « ServiceNow ne marche pas ».
2. 2Vérifier le contexte — Confirmez l’instance, l’application, le rôle, les données de test et les conditions d’exécution.
3. 3Reproduire puis isoler — Refaites les mêmes étapes et comparez un cas fonctionnel. Ne changez qu’un facteur à la fois.
4. 4Consulter et corriger — Vérifiez la documentation pertinente et les règles de votre équipe. Appliquez une modification limitée dans l’environnement approprié.
5. 5Retester et documenter — Testez le cas initial et les scénarios voisins, notez les résultats et partagez un résumé anonymisé si une aide est nécessaire.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation intra-entreprise — OFPPT ofppt.ma
2. Ingénierie de la Formation Continue : Identification et Analyse des Besoins de Formation — OFPPT ofppt.ma
3. Formation ServiceNow — FormaGroup formagroup.ma
4. Now Learning — ServiceNow nowlearning.servicenow.com
5. ServiceNow Developer developer.servicenow.com