Yes, technically you sign (or decrypt) with the privatekey, not with the certificate itself. And a publickey certificate never contains the privatekey.
But a lot of software, and thus documentation, and other description, blurs this distinction. We generally use a privatekey with a certificate (with the exception of SSH, where we attach limited metadata -- a host name or address, and sometimes other restrictions -- directly to a publickey), and the certificate part of this combination is more understandable and interesting to humans.
For example, the Microsoft Windows "Certificate Manager" displays things that are labelled "certificates" organized into things labelled "stores". You can have entries that are simply certificates (for someone else, usually a CA) or entries that are certificates with a privatekey attached (for yourself, or someone you are acting on behalf of). The fields of the certificate are displayed and at least some are meaningful to people: the subject name(s), the validity period, the issuer, sometimes the keyusage and/or extendedkeyusage. (Perhaps the transparency SCT(s) -- well, no, probably not. :-) The privatekey when present is not displayed (for security) and if it was it would be weird incomprehensible gibberish to 99.99% of users.
When you want to sign your email with Outlook, you go to a "Certificate Manager" window and select a "Certificate". Outlook includes this certificate in the outgoing email, and when the recipient displays that email their MUA shows it was "signed by the owner of certificate X" often elided to simply "signed by certificate X". Outlook did in fact use the privatekey to sign as well as putting the matching cert in the message, but the users see and identify and focus on the cert not the privatekey.
This is also reflected in the API; to actually do signing (or decryption) in Windows you get an object of type
X509Certificate2 either from the store or by loading a PFX/PKCS12 file, which actually contains both the certificate and the privatekey.
MacOS keychain is similar, for certs with or without privatekeys (it also does passwords, which are different).
The same is true for TLS/SSL/HTTPS server and optionally client auth -- the privatekey is used internally, but the user(s) and admin(s) see and choose and think about the certificate. This definitely includes IE and Edge, and Chrome on Windows, and to my understanding Safari and Chrome on Mac. Firefox (and NSS) uses its own "cert database" instead of the system one, but it also describes and displays the entries as certificates whether or not they have privatekeys attached.
We often (IME) do the same for certificates themselves, which are also signed objects. For example, a few years ago people experienced trust issues with Google's (then) internal CA, "Google Internet Authority 2", because of the timing of some cross-CA bridging certs, IIRC between Equifax and Geotrust (or maybe the reverse). In answering some of those Qs I believe I talked about, say "this google cert X signed by this other cert Y". That is technically incorrect; to be exact I should have said "this google cert X signed by the abstract entity which is or at the relevant time was the verified owner of the cert Y using the privatekey which is part of the same keypair as the publickey that is in the cert and owned by the same owner as the owner of the cert and generated as a mathematically related unit". If I had done so, and repeated this 5 or 10 times for all the needed links in the cert chain, I would probably never have completed a single answer because it would have been too much work. To someone who knows how public key crypto works, "cert X signed by cert Y" is easily understood even though technically wrong, and to someone who doesn't know, it doesn't make any difference.
BTW, Java goes the opposite way. It has "keystore" files (or sometimes nonfile storage like a PKCS11 token) that can contain (either) lone certs for others, usually a CA, or privatekey-plus-cert entries for yourself. People get these confused just as easily as they do the Windows/Mac/FF approach; I personally have answered at least a dozen Qs here and related Stacks from people who imported a lone cert to their Java keystore when they needed a privatekey plus cert.
GPG traditionally has a "key ring" which contains publickeys with added metadata and (canonically) signature(s) that are in effect certificates, though not called that, and (matching but separate) "secret" keys which are really privatekeys. (This follows PGP, which was designed back in the 1990s before the privatekey-vs-secretkey terminology was settled.) OTOH its newer GUI Kleopatra calls them (together) certificates. Pick your poison.